Re: ipfilter(4) needs maintainer

[Lars Engels]

On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote:
> wishmaster wrote:
> 
> >  --- Original message ---
> > From: "Gary Palmer" 
> > Date: 14 April 2013, 19:06:59
> > 
> >  
> >> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> >>> Is it possible to move ipfilter into a port?
> >> That may work short term, but the ENOMAINTAINER problem will quickly creep
> >> up again as kernel APIs change.  If the author has lost interest in
> >> maintaining the FreeBSD port of ipfilter then unless someone steps forward
> >> to carry on the work, I don't see much of a future for ipfilter in
> >> FreeBSD
> >>
> >> Do we honestly need three packet filters?
> >   
> > Yes! This is the most clever thought in this thread. Why we need
> > 3 firewalls? Two packet filters it's excess too.
> >  We have two packet filters: one with excellent syntax and
> >  functionality but with outdated bandwidth control mechanism
> >  (aka ALTQ); another - with nice traffic shaper/prioritization
> >  (dummynet)/classification (diffused) but with complicated
> >  implementation  in not trivial tasks.
> > May be the next step will be discussion about one packet filter in the 
> > system?..
> > 
> > Cheers,
> For non-nat ipfw is still superior in every way, numbered rules (think: 
> scripts), dummynet, much faster than pf, syntax is a lot nicer and 
> predictable...
> 
> Does anyone even use ipf? it doesn't even work on Linux anymore, junk it 
> and keep pf+ipfw, job done.

m0n0wall uses ipfilter:

http://m0n0.ch/wall/facts.php


pgpWGfUPgq5yV.pgp
Description: PGP signature

Re: ipfilter(4) needs maintainer

[Lev Serebryakov]

Hello, Mark.
You wrote 15 апреля 2013 г., 2:25:07:

>> Yes! This is the most clever thought in this thread. Why we need 3
>> firewalls? Two packet filters it's excess too. We have two packet filters:
>> one with excellent syntax and functionality but with outdated bandwidth
>> control mechanism (aka ALTQ); another - with nice traffic
>> shaper/prioritization (dummynet)/classification (diffused) but with
>> complicated implementation  in not trivial tasks. May be the next step
>> will be discussion about one packet filter in the system?..

MM> ... and as far as I can tell none of them is currently usable
MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
 IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
render all that NAT nightmare to void. I hope, IPv6 prefix translation
will not be possible never ever!

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Kimmo Paasiala]

On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov  wrote:
> Hello, Mark.
> You wrote 15 апреля 2013 г., 2:25:07:
>
>>> Yes! This is the most clever thought in this thread. Why we need 3
>>> firewalls? Two packet filters it's excess too. We have two packet filters:
>>> one with excellent syntax and functionality but with outdated bandwidth
>>> control mechanism (aka ALTQ); another - with nice traffic
>>> shaper/prioritization (dummynet)/classification (diffused) but with
>>> complicated implementation  in not trivial tasks. May be the next step
>>> will be discussion about one packet filter in the system?..
>
> MM> ... and as far as I can tell none of them is currently usable
> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> render all that NAT nightmare to void. I hope, IPv6 prefix translation
> will not be possible never ever!
>
> --
> // Black Lion AKA Lev Serebryakov 
>

Things like ftp-proxy(8) will need address translation even with IPv6.
Also certain scrub options require a NAT like functionalities.

-Kimmo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Lev Serebryakov]

Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:26:40:

>> MM> ... and as far as I can tell none of them is currently usable
>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
>> render all that NAT nightmare to void. I hope, IPv6 prefix translation
>> will not be possible never ever!

KP> Things like ftp-proxy(8) will need address translation even with IPv6.
  ftp-proxy is solution to help IPv4 NAT. Why do we need it when every
device could have routable IPv6? Of course, _every_ device should be
protected by border firewall (stateful and IPv6-enabled), but FTP
server should have special rules for it to allow traffic pass, not
some "proxy".

 And, yes, NAT64 will be useful for sure, but it is another story,
not IPv6<->IPv6 translation.

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Kimmo Paasiala]

On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:26:40:
>
>>> MM> ... and as far as I can tell none of them is currently usable
>>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>>>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
>>> render all that NAT nightmare to void. I hope, IPv6 prefix translation
>>> will not be possible never ever!
>
> KP> Things like ftp-proxy(8) will need address translation even with IPv6.
>   ftp-proxy is solution to help IPv4 NAT. Why do we need it when every
> device could have routable IPv6? Of course, _every_ device should be
> protected by border firewall (stateful and IPv6-enabled), but FTP
> server should have special rules for it to allow traffic pass, not
> some "proxy".
>
>  And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.
>

You're forgetting set ups where outgoing traffic is controlled by
filter rules, outgoing passive mode ftp needs help from the proxy to
open holes for arbitrary ports. This is not limited to IPv4 and NAT.

-Kimmo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Lev Serebryakov]

Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:36:27:

>>  And, yes, NAT64 will be useful for sure, but it is another story,
>> not IPv6<->IPv6 translation.
KP> You're forgetting set ups where outgoing traffic is controlled by
KP> filter rules, outgoing passive mode ftp needs help from the proxy to
KP> open holes for arbitrary ports. This is not limited to IPv4 and NAT.
   It could  be  done without IPv6 prefix mapping. Yes, firewall should
 have  ability  to expect some connections fro FTP commands (some flag
 on rule, for sure), but it is not prefix rewriting (there are some
 other protocols, which need similar treatment, like SIP)! I was
 shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own
 problems and complications, but one REALLY GOOD side of it, that we
 don't need NAT for it anymore! Some special tricks in firewall -- yes,
 maybe, for bad-designed, but widely-deployed application level
 protocols, but not address translations!

  I, personally, don't see any problems to enable all outbound
 connections for dedicated FTP server, though.

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Kimmo Paasiala]

On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:36:27:
>
>>>  And, yes, NAT64 will be useful for sure, but it is another story,
>>> not IPv6<->IPv6 translation.
> KP> You're forgetting set ups where outgoing traffic is controlled by
> KP> filter rules, outgoing passive mode ftp needs help from the proxy to
> KP> open holes for arbitrary ports. This is not limited to IPv4 and NAT.
>It could  be  done without IPv6 prefix mapping. Yes, firewall should
>  have  ability  to expect some connections fro FTP commands (some flag
>  on rule, for sure), but it is not prefix rewriting (there are some
>  other protocols, which need similar treatment, like SIP)! I was
>  shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own
>  problems and complications, but one REALLY GOOD side of it, that we
>  don't need NAT for it anymore! Some special tricks in firewall -- yes,
>  maybe, for bad-designed, but widely-deployed application level
>  protocols, but not address translations!
>
>   I, personally, don't see any problems to enable all outbound
>  connections for dedicated FTP server, though.
>

Server side is the easy part, no need for proxy because you know the
passive mode data ports and you can open holes in your firewall using
the known port numbers.

I'm however talking about an ftp client behind a very restrictive
firewall making an IPv6 connection an ftp server that uses passive
mode data ports that can't be known in advance.

-Kimmo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Lev Serebryakov]

Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:47:24:

KP> I'm however talking about an ftp client behind a very restrictive
KP> firewall making an IPv6 connection an ftp server that uses passive
KP> mode data ports that can't be known in advance.
  Same solution -- inspection of connections to 21 port, without any
 address translation. And if FTP server uses non-standard control
 port, yes, here is a problem, but it cannot be solved with NAT too
 (or your NAT/firewall should expect each and every connection for FTP
 commands, which is heavy and error-prone task).

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Kimmo Paasiala]

On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:47:24:
>
> KP> I'm however talking about an ftp client behind a very restrictive
> KP> firewall making an IPv6 connection an ftp server that uses passive
> KP> mode data ports that can't be known in advance.
>   Same solution -- inspection of connections to 21 port, without any
>  address translation. And if FTP server uses non-standard control
>  port, yes, here is a problem, but it cannot be solved with NAT too
>  (or your NAT/firewall should expect each and every connection for FTP
>  commands, which is heavy and error-prone task).
>

Mmm, are you thinking of the way Linux iptables handles this scenario
with a kernel mode helper? I don't think any of the three packet
filters in FreeBSD has a functionality like that yet.

-Kimmo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[sthaug]

> >> MM> ... and as far as I can tell none of them is currently usable
> >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
> >>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> >> render all that NAT nightmare to void. I hope, IPv6 prefix translation
> >> will not be possible never ever!
> 
> KP> Things like ftp-proxy(8) will need address translation even with IPv6.
>   ftp-proxy is solution to help IPv4 NAT. Why do we need it when every
> device could have routable IPv6? Of course, _every_ device should be
> protected by border firewall (stateful and IPv6-enabled), but FTP
> server should have special rules for it to allow traffic pass, not
> some "proxy".
> 
>  And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.

We are *way* too late in the game to completely avoid IPv6 NAT. Various
flavors already exist in the form of RFCs, e.g. NPTv6:

http://tools.ietf.org/html/rfc6296

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Kimmo Paasiala]

On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala  wrote:
> On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov  wrote:
>> Hello, Kimmo.
>> You wrote 15 апреля 2013 г., 14:47:24:
>>
>> KP> I'm however talking about an ftp client behind a very restrictive
>> KP> firewall making an IPv6 connection an ftp server that uses passive
>> KP> mode data ports that can't be known in advance.
>>   Same solution -- inspection of connections to 21 port, without any
>>  address translation. And if FTP server uses non-standard control
>>  port, yes, here is a problem, but it cannot be solved with NAT too
>>  (or your NAT/firewall should expect each and every connection for FTP
>>  commands, which is heavy and error-prone task).
>>
>
> Mmm, are you thinking of the way Linux iptables handles this scenario
> with a kernel mode helper? I don't think any of the three packet
> filters in FreeBSD has a functionality like that yet.
>
> -Kimmo

To elaborate on this, Linux iptables has a "related" qualifier for
rules and the "related" traffic is identified by kernel mode helpers,
ftp is one example for their use.

-Kimmo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Current problem reports assigned to freebsd-net@FreeBSD.org

[FreeBSD bugmaster]

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/177618  net[bridge] Problem with bridge firewall with trunk ports
o kern/177417  net[ip6] Invalid protocol value in ipsec6_common_input_cb
o kern/177402  net[igb] [pf] problem with ethernet driver igb + pf / alt
o kern/177400  net[jme] JMC25x 1000baseT establishment issues
o kern/177366  net[ieee80211] negative malloc(9) statistics for 80211nod
o kern/177362  net[netinet] [patch] Wrong control used to return TOS
o kern/177194  net[netgraph] Unnamed netgraph nodes for vlan interfaces
o kern/177184  net[bge] [patch] enable wake on lan
o kern/177139  net[igb] igb drops ethernet ports 2 and 3
o kern/176884  net[re] re0 flapping up/down
o kern/176671  net[epair] MAC address for epair device not unique
o kern/176667  net[libalias] [patch] libalias locks on uninitalized data
o kern/176596  net[firewire] [ip6] Crash with IPv6 and Firewire
o kern/176484  net[ipsec] [enc] [patch] panic: IPsec + enc(4); device na
o kern/176446  net[netinet] [patch] Concurrency in ixgbe driving out-of-
o kern/176420  net[kernel] [patch] incorrect errno for LOCAL_PEERCRED
o kern/176419  net[kernel] [patch] socketpair support for LOCAL_PEERCRED
o kern/176401  net[netgraph] page fault  in netgraph
o kern/176167  net[ipsec][lagg] using lagg and ipsec causes immediate pa
o kern/176097  net[lagg] [patch] lagg/lacp broken when aggregated interf
o kern/176027  net[em] [patch] flow control systcl consistency for em dr
o kern/176026  net[tcp] [patch] TCP wrappers caused quite a lot of warni
o bin/175974   netppp(8): logic issue
o kern/175864  net[re] Intel MB D510MO, onboard ethernet not working aft
o kern/175852  net[amd64] [patch] in_cksum_hdr() behaves differently on 
o kern/175734  netno ethernet detected on system with EG20T PCH chipset 
o kern/175267  net[pf] [tap] pf + tap keep state problem
o kern/175236  net[epair] [gif] epair and gif Devices On Bridge
o kern/175182  net[panic] kernel panic on RADIX_MPATH when deleting rout
o kern/175153  net[tcp] will there miss a FIN when do TSO?
o kern/174959  net[net] [patch] rnh_walktree_from visits spurious nodes
o kern/174958  net[net] [patch] rnh_walktree_from makes unreasonable ass
o kern/174897  net[route] Interface routes are broken
o kern/174851  net[bxe] [patch] UDP checksum offload is wrong in bxe dri
o kern/174850  net[bxe] [patch] bxe driver does not receive multicasts
o kern/174849  net[bxe] [patch] bxe driver can hang kernel when reset
o kern/174822  net[tcp] Page fault in tcp_discardcb under high traffic
o kern/174602  net[gif] [ipsec] traceroute issue on gif tunnel with ipse
o kern/174535  net[tcp] TCP fast retransmit feature works strange
o kern/173871  net[gif] process of 'ifconfig gif0 create hangs' when if_
o kern/173475  net[tun] tun(4) stays opened by PID after process is term
o kern/173201  net[ixgbe] [patch] Missing / broken ixgbe sysctl's and tu
o kern/173137  net[em] em(4) unable to run at gigabit with 9.1-RC2
o kern/173002  net[patch] data type size problem in if_spppsubr.c
o kern/172985  net[patch] [ip6] lltable leak when adding and removing IP
o kern/172895  net[ixgb] [ixgbe] do not properly determine link-state
o kern/172683  net[ip6] Duplicate IPv6 Link Local Addresses
o kern/172675  net[netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos
o kern/172113  net[panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4
o kern/171840  net[ip6] IPv6 packets transmitting only on queue 0
o kern/171739  net[bce] [panic] bce related kernel panic
o kern/171711  net[dummynet] [panic] Kernel panic in dummynet
o kern/171532  net[ndis] ndis(4) driver includes 'pccard'-specific code,
o kern/171531  net[ndis] undocumented dependency for ndis(4)
o kern/171524  net[ipmi] ipmi driver crashes kernel by reboot or shutdow
s kern/171508  net[epair] [request] Add the ability to name epair device
o kern/171228  net[re] [patch] if_re - eeprom write issues
o kern/170701  net[ppp] killl ppp or reboot with active ppp connection c
o kern/170267  net[ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona
o kern/170081  net[fxp] pf/nat/jails not working if checksum offloading 
o kern/169898  netifconfig(8) fails to set M

Re: ipfilter(4) needs maintainer

[Mark Martinec]

On Monday April 15 2013 12:32:37 Lev Serebryakov wrote:
> And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.

Fear not, NPT66 prefix translation is stateless,
this is nothing like NAT44 / NAPT.

On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote:
> We are *way* too late in the game to completely avoid IPv6 NAT.
> Various flavors already exist in the form of RFCs, e.g. NPTv6:
>   http://tools.ietf.org/html/rfc6296

Prefix translation is useful for SOHO or branch offices with
more than one uplink, unless one wants to invest into AS and BGP
or start building tunnels:

  http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html


Mark
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message , Warren Block 
writ
es:
> On Sun, 14 Apr 2013, Chris Rees wrote:
> 
> > On 14 April 2013 01:41, Rui Paulo  wrote:
> >> 2013/04/13 16:01?Scott Long  ??:
> >>
> >>> Maybe something else, but whatever it is, it should be done.  If you and 
> Gleb don't want to do this, I will.
> >>
> >> I already started writing a guide. See here for a very incomplete version:
> >>
> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
> >
> > If you're really serious about deprecating ipf, we absolutely have to
> > remove instructions for it from the Handbook as soon as possible;
> > every time a new user comes across instructions you're going to have
> > yet another annoyed party.
> >
> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff
> 
> This should probably be done like we did for CVS for ports.  Mark it as 
> deprecated, then remove the Handbook section once the code is removed.

Sorry, I'm coming in late on this discussion. I'm willing to take it on as 
I've been planning on updating it for a while. Would a src committer like 
to take me on for mentorship?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[cpet]

Ok, seems someone has taken the job.


> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo  wrote:
>> >> 2013/04/13 16:01?Scott Long  ??:
>> >>
>> >>> Maybe something else, but whatever it is, it should be done.  If you
>> and
>> Gleb don't want to do this, I will.
>> >>
>> >> I already started writing a guide. See here for a very incomplete
>> version:
>> >>
>> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
>> >
>> > If you're really serious about deprecating ipf, we absolutely have to
>> > remove instructions for it from the Handbook as soon as possible;
>> > every time a new user comes across instructions you're going to have
>> > yet another annoyed party.
>> >
>> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff
>>
>> This should probably be done like we did for CVS for ports.  Mark it as
>> deprecated, then remove the Handbook section once the code is removed.
>
> Sorry, I'm coming in late on this discussion. I'm willing to take it on as
> I've been planning on updating it for a while. Would a src committer like
> to take me on for mentorship?
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
>
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[cpet]

However it would of been better if said person asked me as I already
offered to take it on but whatever.


> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo  wrote:
>> >> 2013/04/13 16:01?Scott Long  ??:
>> >>
>> >>> Maybe something else, but whatever it is, it should be done.  If you
>> and
>> Gleb don't want to do this, I will.
>> >>
>> >> I already started writing a guide. See here for a very incomplete
>> version:
>> >>
>> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
>> >
>> > If you're really serious about deprecating ipf, we absolutely have to
>> > remove instructions for it from the Handbook as soon as possible;
>> > every time a new user comes across instructions you're going to have
>> > yet another annoyed party.
>> >
>> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff
>>
>> This should probably be done like we did for CVS for ports.  Mark it as
>> deprecated, then remove the Handbook section once the code is removed.
>
> Sorry, I'm coming in late on this discussion. I'm willing to take it on as
> I've been planning on updating it for a while. Would a src committer like
> to take me on for mentorship?
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
>
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

I've been planning on taking on IP Filter for quite some time. 
Unfortunately I've left my src commit bit lapse (my ports commit bit is 
alive and well though) thus I'm looking for a mentor. In addition I'm 
working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
would be fine too.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


In message <8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org>, 
c...@sdf.org
 writes:
> Ok, seems someone has taken the job.
> 
> 
> > In message , Warren Block
> > writ
> > es:
> >> On Sun, 14 Apr 2013, Chris Rees wrote:
> >>
> >> > On 14 April 2013 01:41, Rui Paulo  wrote:
> >> >> 2013/04/13 16:01?Scott Long  ??:
> >> >>
> >> >>> Maybe something else, but whatever it is, it should be done.  If you
> >> and
> >> Gleb don't want to do this, I will.
> >> >>
> >> >> I already started writing a guide. See here for a very incomplete
> >> version:
> >> >>
> >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
> >> >
> >> > If you're really serious about deprecating ipf, we absolutely have to
> >> > remove instructions for it from the Handbook as soon as possible;
> >> > every time a new user comes across instructions you're going to have
> >> > yet another annoyed party.
> >> >
> >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff
> >>
> >> This should probably be done like we did for CVS for ports.  Mark it as
> >> deprecated, then remove the Handbook section once the code is removed.
> >
> > Sorry, I'm coming in late on this discussion. I'm willing to take it on as
> > I've been planning on updating it for a while. Would a src committer like
> > to take me on for mentorship?
> >
> >
> > --
> > Cheers,
> > Cy Schubert 
> > FreeBSD UNIX: Web:  http://www.FreeBSD.org
> >
> >
> > ___
> > freebsd-curr...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> 
> 


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Rui Paulo]

2013/04/15 9:55、Cy Schubert  のメッセージ:

> I've been planning on taking on IP Filter for quite some time. 
> Unfortunately I've left my src commit bit lapse (my ports commit bit is 
> alive and well though) thus I'm looking for a mentor. In addition I'm 
> working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
> would be fine too.

What are your plans regarding ipfilter? I remain unconvinced that it should be 
in the base system. Perhaps you can work on it as a port?

Why do you want to work on something that people have been trying to remove 
since 2005?

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

VLANHWFILTER "upgrade"

[Alexander V. Chernikov]

Hello list.

We currently have VLAHWFILTER functionality allowing underlying
physical/virtual interfaces to be aware of vlans stacked on them.

However, this knowledge is only used to program NIC hw filter (or to
broadcast to member ifaces in lagg case).

Proposed idea is to save vlan ifp pointer inside the driver and push
packet to given vlan directly.

This changes removes 1 read lock on RX fast path.

Additionally, we can do the same in more popular case of

ix -> lagg [ -> lagg -> lagg ] -> vlan

if we solve
1) lagg interface counters issue (trivial)
2) IFF_MONITOR on lagg interface issue (not so trivial, unfortunately).

Patch to ixgbe driver attached (maybe it is better to put
ixgbe_vlan_get() and struct ifvlans directly to if_vlan.[ch]).


-- 
WBR, Alexander
Index: sys/dev/ixgbe/ixgbe.c
===
--- sys/dev/ixgbe/ixgbe.c   (revision 248704)
+++ sys/dev/ixgbe/ixgbe.c   (working copy)
@@ -2880,6 +2880,14 @@ ixgbe_allocate_queues(struct adapter *adapter)
error = ENOMEM;
goto err_rx_desc;
}
+
+   if ((rxr->vlans = malloc(sizeof(struct ifvlans), M_DEVBUF,
+   M_NOWAIT | M_ZERO)) == NULL) {
+   device_printf(dev,
+   "Critical Failure setting up vlan index\n");
+   error = ENOMEM;
+   goto err_rx_desc;
+   }
}
 
/*
@@ -4271,6 +4279,11 @@ ixgbe_free_receive_buffers(struct rx_ring *rxr)
rxr->ptag = NULL;
}
 
+   if (rxr->vlans != NULL) {
+   free(rxr->vlans, M_DEVBUF);
+   rxr->vlans = NULL;
+   }
+
return;
 }
 
@@ -4303,7 +4316,7 @@ ixgbe_rx_input(struct rx_ring *rxr, struct ifnet *
 return;
 }
IXGBE_RX_UNLOCK(rxr);
-(*ifp->if_input)(ifp, m);
+(*ifp->if_input)(m->m_pkthdr.rcvif, m);
IXGBE_RX_LOCK(rxr);
 }
 
@@ -4360,6 +4373,7 @@ ixgbe_rxeof(struct ix_queue *que)
u16 count = rxr->process_limit;
union ixgbe_adv_rx_desc *cur;
struct ixgbe_rx_buf *rbuf, *nbuf;
+   struct ifnet*ifp_dst;
 
IXGBE_RX_LOCK(rxr);
 
@@ -4522,9 +4536,19 @@ ixgbe_rxeof(struct ix_queue *que)
(staterr & IXGBE_RXD_STAT_VP))
vtag = le16toh(cur->wb.upper.vlan);
if (vtag) {
-   sendmp->m_pkthdr.ether_vtag = vtag;
-   sendmp->m_flags |= M_VLANTAG;
-   }
+   ifp_dst = rxr->vlans->idx[EVL_VLANOFTAG(vtag)];
+
+   if (ifp_dst != NULL) {
+   ifp_dst->if_ipackets++;
+   sendmp->m_pkthdr.rcvif = ifp_dst;
+   } else {
+   sendmp->m_pkthdr.ether_vtag = vtag;
+   sendmp->m_flags |= M_VLANTAG;
+   sendmp->m_pkthdr.rcvif = ifp;
+   }
+   } else
+   sendmp->m_pkthdr.rcvif = ifp;
+
if ((ifp->if_capenable & IFCAP_RXCSUM) != 0)
ixgbe_rx_checksum(staterr, sendmp, ptype);
 #if __FreeBSD_version >= 80
@@ -4625,7 +4649,32 @@ ixgbe_rx_checksum(u32 staterr, struct mbuf * mp, u
return;
 }
 
+/*
+ * This routine gets real vlan ifp based on
+ * underlying ifp and vlan tag.
+ */
+static struct ifnet *
+ixgbe_get_vlan(struct ifnet *ifp, uint16_t vtag)
+{
 
+   /* XXX: IFF_MONITOR */
+#if 0
+   struct lagg_port *lp = ifp->if_lagg;
+   struct lagg_softc *sc = lp->lp_softc;
+
+   /* Skip lagg nesting */
+   while (ifp->if_type == IFT_IEEE8023ADLAG) {
+   lp = ifp->if_lagg;
+   sc = lp->lp_softc;
+   ifp = sc->sc_ifp;
+   }
+#endif
+   /* Get vlan interface based on tag */
+   ifp = VLAN_DEVAT(ifp, vtag);
+
+   return (ifp);
+}
+
 /*
 ** This routine is run via an vlan config EVENT,
 ** it enables us to use the HW Filter table since
@@ -4637,7 +4686,9 @@ static void
 ixgbe_register_vlan(void *arg, struct ifnet *ifp, u16 vtag)
 {
struct adapter  *adapter = ifp->if_softc;
-   u16 index, bit;
+   u16 index, bit, j;
+   struct rx_ring  *rxr;
+   struct ifnet*ifv;
 
if (ifp->if_softc !=  arg)   /* Not our event */
return;
@@ -4645,7 +4696,20 @@ ixgbe_register_vlan(void *arg, struct ifnet *ifp,
if ((vtag == 0) || (vtag > 4095))   /* Invalid */
return;
 
+   ifv = ixgbe_get_vlan(ifp, vtag);
+
IXGBE_CORE_LOCK(adapter);
+
+   if (ifp->if_capenable & IFCAP_VLAN_HWFILT

Re: ipfilter(4) needs maintainer

[Adrian Chadd]

ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_.



Adrian

On 15 April 2013 09:55, Cy Schubert  wrote:
> I've been planning on taking on IP Filter for quite some time.
> Unfortunately I've left my src commit bit lapse (my ports commit bit is
> alive and well though) thus I'm looking for a mentor. In addition I'm
> working on an ACER WMI/ACPI kld. One mentor would be preferred but two
> would be fine too.
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
>
> In message <8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org>,
> c...@sdf.org
>  writes:
>> Ok, seems someone has taken the job.
>>
>>
>> > In message , Warren Block
>> > writ
>> > es:
>> >> On Sun, 14 Apr 2013, Chris Rees wrote:
>> >>
>> >> > On 14 April 2013 01:41, Rui Paulo  wrote:
>> >> >> 2013/04/13 16:01?Scott Long  ??:
>> >> >>
>> >> >>> Maybe something else, but whatever it is, it should be done.  If you
>> >> and
>> >> Gleb don't want to do this, I will.
>> >> >>
>> >> >> I already started writing a guide. See here for a very incomplete
>> >> version:
>> >> >>
>> >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
>> >> >
>> >> > If you're really serious about deprecating ipf, we absolutely have to
>> >> > remove instructions for it from the Handbook as soon as possible;
>> >> > every time a new user comes across instructions you're going to have
>> >> > yet another annoyed party.
>> >> >
>> >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff
>> >>
>> >> This should probably be done like we did for CVS for ports.  Mark it as
>> >> deprecated, then remove the Handbook section once the code is removed.
>> >
>> > Sorry, I'm coming in late on this discussion. I'm willing to take it on as
>> > I've been planning on updating it for a while. Would a src committer like
>> > to take me on for mentorship?
>> >
>> >
>> > --
>> > Cheers,
>> > Cy Schubert 
>> > FreeBSD UNIX: Web:  http://www.FreeBSD.org
>> >
>> >
>> > ___
>> > freebsd-curr...@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> >
>>
>>
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo 
writes:
> 2013/04/15 9:55$B!"(BCy Schubert  
> $B$N%a%C%;!<%8(B:
> 
> > I've been planning on taking on IP Filter for quite some time. 
> > Unfortunately I've left my src commit bit lapse (my ports commit bit is 
> > alive and well though) thus I'm looking for a mentor. In addition I'm 
> > working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
> > would be fine too.
> 
> What are your plans regarding ipfilter? I remain unconvinced that it should b
> e in the base system. Perhaps you can work on it as a port?

The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
done much with IPF while employed with Sun. Since then there has been some 
development that is long overdue for HEAD.

I'm not sure if I'd MFC it into 9 or not.

I did consider a port but given it would has to touch bits and pieces of 
the source tree (/usr/src), a port would be messy and the decision was made 
to work on importing it into base.

> 
> Why do you want to work on something that people have been trying to remove s
> ince 2005?

I and others have been using it in FreeBSD for over decade. For the longest 
of time we'd use a common set of rules across a FreeBSD and Solaris farm 
(using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). 
Interoperability with other systems which use IP Filter is a plus. If 
there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would 
be a loss.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

using netmap

[Sami Halabi]

Hi,
I would like to start using netmap.

as a start i copied the example from netmap
page:
#include 
#include 
#include 
#include 

int main() {

struct netmap_if *nifp;
struct nmreq req;
int i, len;
char *buf;
FILE* fd;

fd = open("/dev/netmap", 0);
strcpy(req.nr_name, "em1"); // register the interface
ioctl(fd, NIOCREG, &req); // offset of the structure
mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0);
nifp = NETMAP_IF(mem, req.nr_offset);
for (;;) {
struct pollfd x[1];
struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0);

x[0].fd = fd;
x[0].events = POLLIN;
poll(x, 1, 1000);
for ( ; ring->avail > 0 ; ring->avail--) {
i = ring->cur;
buf = NETMAP_BUF(ring, i);
use_data(buf, ring->slot[i].len);
ring->cur = NETMAP_NEXT(ring, i);
}
}

return 0;
}


and tried to compile:
root@fbsd1:~/netmap # gcc -O2 -pipe -Werror -Wall -I ../sys -Wextra -c n.c
In file included from n.c:4:
/usr/include/net/netmap.h:139: error: expected specifier-qualifier-list
before 'uint32_t'
/usr/include/net/netmap.h:228: error: expected ':', ',', ';', '}' or
'__attribute__' before 'num_slots'
/usr/include/net/netmap.h:255: error: 'IFNAMSIZ' undeclared here (not in a
function)
/usr/include/net/netmap.h:256: error: expected ':', ',', ';', '}' or
'__attribute__' before 'ni_version'
/usr/include/net/netmap.h:292: error: expected specifier-qualifier-list
before 'uint32_t'
cc1: warnings being treated as errors
n.c: In function 'main':
n.c:14: warning: implicit declaration of function 'open'
n.c:14: warning: assignment makes pointer from integer without a cast
n.c:15: warning: implicit declaration of function 'strcpy'
n.c:15: warning: incompatible implicit declaration of built-in function
'strcpy'
n.c:16: warning: implicit declaration of function 'ioctl'
n.c:16: error: 'NIOCREG' undeclared (first use in this function)
n.c:16: error: (Each undeclared identifier is reported only once
n.c:16: error: for each function it appears in.)
n.c:17: error: 'mem' undeclared (first use in this function)
n.c:17: error: 'struct nmreq' has no member named 'nr_memsize'
n.c:17: error: 'PROT_READ' undeclared (first use in this function)
n.c:17: error: 'PROT_WRITE' undeclared (first use in this function)
n.c:17: warning: passing argument 5 of 'mmap' makes integer from pointer
without a cast
n.c:18: error: 'struct nmreq' has no member named 'nr_offset'
n.c:20: error: array type has incomplete element type
n.c:21: warning: implicit declaration of function 'NETMAP_RX_RING'
n.c:21: warning: initialization makes pointer from integer without a cast
n.c:24: error: 'POLLIN' undeclared (first use in this function)
n.c:25: warning: implicit declaration of function 'poll'
n.c:26: error: 'struct netmap_ring' has no member named 'avail'
n.c:26: error: 'struct netmap_ring' has no member named 'avail'
n.c:27: error: 'struct netmap_ring' has no member named 'cur'
n.c:28: error: 'struct netmap_ring' has no member named 'nr_buf_size'
n.c:29: warning: implicit declaration of function 'use_data'
n.c:29: error: 'struct netmap_ring' has no member named 'slot'
n.c:30: error: 'struct netmap_ring' has no member named 'cur'
n.c:30: warning: implicit declaration of function 'NETMAP_NEXT'
n.c:20: warning: unused variable 'x'
n.c:10: warning: unused variable 'len'
root@fbsd1:~/netmap #


can you help me figure it out?

Thanks in advance,

-- 
Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: using netmap

[Andreas Nilsson]

On Mon, Apr 15, 2013 at 7:52 PM, Sami Halabi  wrote:

> Hi,
> I would like to start using netmap.
>
> as a start i copied the example from netmap
> page:
> #include 
> #include 
> #include 
> #include 
>
> int main() {
>
> struct netmap_if *nifp;
> struct nmreq req;
> int i, len;
> char *buf;
> FILE* fd;
>
> fd = open("/dev/netmap", 0);
> strcpy(req.nr_name, "em1"); // register the interface
> ioctl(fd, NIOCREG, &req); // offset of the structure
> mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0);
> nifp = NETMAP_IF(mem, req.nr_offset);
> for (;;) {
> struct pollfd x[1];
> struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0);
>
> x[0].fd = fd;
> x[0].events = POLLIN;
> poll(x, 1, 1000);
> for ( ; ring->avail > 0 ; ring->avail--) {
> i = ring->cur;
> buf = NETMAP_BUF(ring, i);
> use_data(buf, ring->slot[i].len);
> ring->cur = NETMAP_NEXT(ring, i);
> }
> }
>
> return 0;
> }
>
>
> and tried to compile:
> root@fbsd1:~/netmap # gcc -O2 -pipe -Werror -Wall -I ../sys -Wextra -c n.c
> In file included from n.c:4:
> /usr/include/net/netmap.h:139: error: expected specifier-qualifier-list
> before 'uint32_t'
> /usr/include/net/netmap.h:228: error: expected ':', ',', ';', '}' or
> '__attribute__' before 'num_slots'
> /usr/include/net/netmap.h:255: error: 'IFNAMSIZ' undeclared here (not in a
> function)
> /usr/include/net/netmap.h:256: error: expected ':', ',', ';', '}' or
> '__attribute__' before 'ni_version'
> /usr/include/net/netmap.h:292: error: expected specifier-qualifier-list
> before 'uint32_t'
> cc1: warnings being treated as errors
> n.c: In function 'main':
> n.c:14: warning: implicit declaration of function 'open'
> n.c:14: warning: assignment makes pointer from integer without a cast
> n.c:15: warning: implicit declaration of function 'strcpy'
> n.c:15: warning: incompatible implicit declaration of built-in function
> 'strcpy'
> n.c:16: warning: implicit declaration of function 'ioctl'
> n.c:16: error: 'NIOCREG' undeclared (first use in this function)
> n.c:16: error: (Each undeclared identifier is reported only once
> n.c:16: error: for each function it appears in.)
> n.c:17: error: 'mem' undeclared (first use in this function)
> n.c:17: error: 'struct nmreq' has no member named 'nr_memsize'
> n.c:17: error: 'PROT_READ' undeclared (first use in this function)
> n.c:17: error: 'PROT_WRITE' undeclared (first use in this function)
> n.c:17: warning: passing argument 5 of 'mmap' makes integer from pointer
> without a cast
> n.c:18: error: 'struct nmreq' has no member named 'nr_offset'
> n.c:20: error: array type has incomplete element type
> n.c:21: warning: implicit declaration of function 'NETMAP_RX_RING'
> n.c:21: warning: initialization makes pointer from integer without a cast
> n.c:24: error: 'POLLIN' undeclared (first use in this function)
> n.c:25: warning: implicit declaration of function 'poll'
> n.c:26: error: 'struct netmap_ring' has no member named 'avail'
> n.c:26: error: 'struct netmap_ring' has no member named 'avail'
> n.c:27: error: 'struct netmap_ring' has no member named 'cur'
> n.c:28: error: 'struct netmap_ring' has no member named 'nr_buf_size'
> n.c:29: warning: implicit declaration of function 'use_data'
> n.c:29: error: 'struct netmap_ring' has no member named 'slot'
> n.c:30: error: 'struct netmap_ring' has no member named 'cur'
> n.c:30: warning: implicit declaration of function 'NETMAP_NEXT'
> n.c:20: warning: unused variable 'x'
> n.c:10: warning: unused variable 'len'
> root@fbsd1:~/netmap #
>
>
> can you help me figure it out?
>
> Thanks in advance,
>
> --
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert
> FreeBSD SysAdmin Expert
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>

Hello Sami,

First, I'm by no means an expert on NETMAP, but the url you provided says
that it's a snapshot, not a ready progam. There are a few fully working
examples in tools/tools/netmap/ subdir of at least 9-STABLE and 10-CURRENT.
Maybe you can find an example to start with there instead?

Quite a few of the errors are from regular syscalls, and each of them have
a manpage that says which files to include, and compiling stuff with
-Werror assumes you can deal with "picky" compilers.

Hope you come up with a working example.

Best regards
Andreas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Sam Fourman Jr.]

Thank you to those that have expressed interest in maintaining IP Filter..

My thoughts are, could we consider putting a option in the kernel config,
and leaving it off by default for GENERIC?
I think this is a acceptable compromise, considering some people wish for
it to be removed.

Sam Fourman Jr.


On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrote:

> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> writes:
> > 2013/04/15 9:55、Cy Schubert  のメッセージ:
> >
> > > I've been planning on taking on IP Filter for quite some time.
> > > Unfortunately I've left my src commit bit lapse (my ports commit bit is
> > > alive and well though) thus I'm looking for a mentor. In addition I'm
> > > working on an ACER WMI/ACPI kld. One mentor would be preferred but two
> > > would be fine too.
> >
> > What are your plans regarding ipfilter? I remain unconvinced that it
> should b
> > e in the base system. Perhaps you can work on it as a port?
>
> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
> done much with IPF while employed with Sun. Since then there has been some
> development that is long overdue for HEAD.
>
> I'm not sure if I'd MFC it into 9 or not.
>
> I did consider a port but given it would has to touch bits and pieces of
> the source tree (/usr/src), a port would be messy and the decision was made
> to work on importing it into base.
>
> >
> > Why do you want to work on something that people have been trying to
> remove s
> > ince 2005?
>
> I and others have been using it in FreeBSD for over decade. For the longest
> of time we'd use a common set of rules across a FreeBSD and Solaris farm
> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).
> Interoperability with other systems which use IP Filter is a plus. If
> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would
> be a loss.
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
>
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>



-- 

Sam Fourman Jr.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Scott Long]

The desire to remove it stems from the inability to give it adequate 
engineering 
service as the network stack evolves.  Simply taking it out of a kernel config 
file
doesn't address that problem at all.  If it's going to stay in FreeBSD at all, 
it
needs to be maintained.  This could be set about a fair amount of stuff in 
FreeBSD,
but IPFilter stands out since there's a high rate of needed change happening in
the network stack, and it shouldn't be left to rot nor to be a stumbling block 
for
those changes.

Scott

On Apr 15, 2013, at 12:49 PM, "Sam Fourman Jr."  wrote:

> Thank you to those that have expressed interest in maintaining IP Filter..
> 
> My thoughts are, could we consider putting a option in the kernel config,
> and leaving it off by default for GENERIC?
> I think this is a acceptable compromise, considering some people wish for
> it to be removed.
> 
> Sam Fourman Jr.
> 
> 
> On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrote:
> 
>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
>> writes:
>>> 2013/04/15 9:55、Cy Schubert  のメッセージ:
>>> 
 I've been planning on taking on IP Filter for quite some time.
 Unfortunately I've left my src commit bit lapse (my ports commit bit is
 alive and well though) thus I'm looking for a mentor. In addition I'm
 working on an ACER WMI/ACPI kld. One mentor would be preferred but two
 would be fine too.
>>> 
>>> What are your plans regarding ipfilter? I remain unconvinced that it
>> should b
>>> e in the base system. Perhaps you can work on it as a port?
>> 
>> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
>> done much with IPF while employed with Sun. Since then there has been some
>> development that is long overdue for HEAD.
>> 
>> I'm not sure if I'd MFC it into 9 or not.
>> 
>> I did consider a port but given it would has to touch bits and pieces of
>> the source tree (/usr/src), a port would be messy and the decision was made
>> to work on importing it into base.
>> 
>>> 
>>> Why do you want to work on something that people have been trying to
>> remove s
>>> ince 2005?
>> 
>> I and others have been using it in FreeBSD for over decade. For the longest
>> of time we'd use a common set of rules across a FreeBSD and Solaris farm
>> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).
>> Interoperability with other systems which use IP Filter is a plus. If
>> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would
>> be a loss.
>> 
>> 
>> --
>> Cheers,
>> Cy Schubert 
>> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>> 
>> 
>> ___
>> freebsd-curr...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> 
> 
> 
> 
> -- 
> 
> Sam Fourman Jr.
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Sam Fourman Jr.]

To my knowledge it is already off by default and you need these options to
enable it

options IPFILTER
options IPFILTER_LOG

so to those that wish to have it removed from base, if it has a maintainer
whats the trouble?



On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr.  wrote:

>
> Thank you to those that have expressed interest in maintaining IP Filter..
>
> My thoughts are, could we consider putting a option in the kernel config,
> and leaving it off by default for GENERIC?
> I think this is a acceptable compromise, considering some people wish for
> it to be removed.
>
> Sam Fourman Jr.
>
>
> On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrote:
>
>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
>> writes:
>> > 2013/04/15 9:55、Cy Schubert  のメッセージ:
>> >
>> > > I've been planning on taking on IP Filter for quite some time.
>> > > Unfortunately I've left my src commit bit lapse (my ports commit bit
>> is
>> > > alive and well though) thus I'm looking for a mentor. In addition I'm
>> > > working on an ACER WMI/ACPI kld. One mentor would be preferred but two
>> > > would be fine too.
>> >
>> > What are your plans regarding ipfilter? I remain unconvinced that it
>> should b
>> > e in the base system. Perhaps you can work on it as a port?
>>
>> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
>> done much with IPF while employed with Sun. Since then there has been some
>> development that is long overdue for HEAD.
>>
>> I'm not sure if I'd MFC it into 9 or not.
>>
>> I did consider a port but given it would has to touch bits and pieces of
>> the source tree (/usr/src), a port would be messy and the decision was
>> made
>> to work on importing it into base.
>>
>> >
>> > Why do you want to work on something that people have been trying to
>> remove s
>> > ince 2005?
>>
>> I and others have been using it in FreeBSD for over decade. For the
>> longest
>> of time we'd use a common set of rules across a FreeBSD and Solaris farm
>> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).
>> Interoperability with other systems which use IP Filter is a plus. If
>> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would
>> be a loss.
>>
>>
>> --
>> Cheers,
>> Cy Schubert 
>> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>>
>>
>> ___
>> freebsd-curr...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
>
>
> --
>
> Sam Fourman Jr.
>



-- 

Sam Fourman Jr.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Scott Long]

On Apr 15, 2013, at 11:48 AM, Cy Schubert  wrote:

> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo 
> writes:
>> 2013/04/15 9:55$B!"(BCy Schubert  
>> $B$N%a%C%;!<%8(B:
>> 
>>> I've been planning on taking on IP Filter for quite some time. 
>>> Unfortunately I've left my src commit bit lapse (my ports commit bit is 
>>> alive and well though) thus I'm looking for a mentor. In addition I'm 
>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
>>> would be fine too.
>> 
>> What are your plans regarding ipfilter? I remain unconvinced that it should b
>> e in the base system. Perhaps you can work on it as a port?
> 
> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
> done much with IPF while employed with Sun. Since then there has been some 
> development that is long overdue for HEAD.
> 
> I'm not sure if I'd MFC it into 9 or not.
> 
> I did consider a port but given it would has to touch bits and pieces of 
> the source tree (/usr/src), a port would be messy and the decision was made 
> to work on importing it into base.
> 
>> 
>> Why do you want to work on something that people have been trying to remove s
>> ince 2005?
> 
> I and others have been using it in FreeBSD for over decade. For the longest 
> of time we'd use a common set of rules across a FreeBSD and Solaris farm 
> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). 
> Interoperability with other systems which use IP Filter is a plus. If 
> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would 
> be a loss.
> 


If you're committed to maintaining IPFilter, that's great.  However, it can't be
left to stagger along in a  zombie state with nothing more than good intentions
from well meaning people.  What is your timeline for getting it back into shape
and re-integrating yourself into the committer community?

Scott
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message , Scott Long 
writes:
> 
> On Apr 15, 2013, at 11:48 AM, Cy Schubert  wrote:
> 
> > In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo 
> > writes:
> >> 2013/04/15 9:55$B!"(BCy Schubert  
> >> $B$N%a%C%;!<%8
> (B:
> >> 
> >>> I've been planning on taking on IP Filter for quite some time. 
> >>> Unfortunately I've left my src commit bit lapse (my ports commit bit is 
> >>> alive and well though) thus I'm looking for a mentor. In addition I'm 
> >>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
> >>> would be fine too.
> >> 
> >> What are your plans regarding ipfilter? I remain unconvinced that it shoul
> d b
> >> e in the base system. Perhaps you can work on it as a port?
> > 
> > The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
> > done much with IPF while employed with Sun. Since then there has been some 
> > development that is long overdue for HEAD.
> > 
> > I'm not sure if I'd MFC it into 9 or not.
> > 
> > I did consider a port but given it would has to touch bits and pieces of 
> > the source tree (/usr/src), a port would be messy and the decision was made
>  
> > to work on importing it into base.
> > 
> >> 
> >> Why do you want to work on something that people have been trying to remov
> e s
> >> ince 2005?
> > 
> > I and others have been using it in FreeBSD for over decade. For the longest
>  
> > of time we'd use a common set of rules across a FreeBSD and Solaris farm 
> > (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). 
> > Interoperability with other systems which use IP Filter is a plus. If 
> > there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would 
> > be a loss.
> > 
> 
> 
> If you're committed to maintaining IPFilter, that's great.  However, it can't
>  be
> left to stagger along in a  zombie state with nothing more than good intentio
> ns
> from well meaning people.  What is your timeline for getting it back into sha
> pe
> and re-integrating yourself into the committer community?

I would think this would be my top priority right now. I'd like to see it 
at the latest level in HEAD. I would like to MFC to 9-STABLE at some point.

Given that IPF already lives in src/contrib and src/sys/contrib, would the 
change in License from Darren Reed's own not so BSD friendly IPF license to 
GPLv2 be of concern. I recall there was a lot of concern over IPF's license 
change at the time. (FreeBSD moved it to contrib while OpenBSD removed it 
completely and wrote PF -- I'm not sure what NetBSD did).


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Scott Long]

On Apr 15, 2013, at 1:27 PM, Cy Schubert  wrote:

> In message , Scott Long 
> writes:
>> 
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert  wrote:
>> 
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo 
>>> writes:
 2013/04/15 9:55$B!"(BCy Schubert  
 $B$N%a%C%;!<%8
>> (B:
 
> I've been planning on taking on IP Filter for quite some time. 
> Unfortunately I've left my src commit bit lapse (my ports commit bit is 
> alive and well though) thus I'm looking for a mentor. In addition I'm 
> working on an ACER WMI/ACPI kld. One mentor would be preferred but two 
> would be fine too.
 
 What are your plans regarding ipfilter? I remain unconvinced that it shoul
>> d b
 e in the base system. Perhaps you can work on it as a port?
>>> 
>>> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
>>> done much with IPF while employed with Sun. Since then there has been some 
>>> development that is long overdue for HEAD.
>>> 
>>> I'm not sure if I'd MFC it into 9 or not.
>>> 
>>> I did consider a port but given it would has to touch bits and pieces of 
>>> the source tree (/usr/src), a port would be messy and the decision was made
>> 
>>> to work on importing it into base.
>>> 
 
 Why do you want to work on something that people have been trying to remov
>> e s
 ince 2005?
>>> 
>>> I and others have been using it in FreeBSD for over decade. For the longest
>> 
>>> of time we'd use a common set of rules across a FreeBSD and Solaris farm 
>>> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). 
>>> Interoperability with other systems which use IP Filter is a plus. If 
>>> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would 
>>> be a loss.
>>> 
>> 
>> 
>> If you're committed to maintaining IPFilter, that's great.  However, it can't
>> be
>> left to stagger along in a  zombie state with nothing more than good intentio
>> ns
>> from well meaning people.  What is your timeline for getting it back into sha
>> pe
>> and re-integrating yourself into the committer community?
> 
> I would think this would be my top priority right now. I'd like to see it 
> at the latest level in HEAD. I would like to MFC to 9-STABLE at some point.
> 
> Given that IPF already lives in src/contrib and src/sys/contrib, would the 
> change in License from Darren Reed's own not so BSD friendly IPF license to 
> GPLv2 be of concern. I recall there was a lot of concern over IPF's license 
> change at the time. (FreeBSD moved it to contrib while OpenBSD removed it 
> completely and wrote PF -- I'm not sure what NetBSD did).
> 


I would assume that the license change would be OK, especially since the other
option is to remove it (or let it continue to rot and be an eyesore) but I'll 
defer to those like
Gleb and Rui with a more vested interest in it.

Scott

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> In message , Scott
> Long writes:
>> 
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert
>>  wrote:
>> 
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>,
>>> Rui Paulo writes:
 2013/04/15 9:55$B!"(BCy Schubert 
 $B$N%a%C%;!<%8
>> (B:
 
> I've been planning on taking on IP Filter for quite some
> time. Unfortunately I've left my src commit bit lapse (my
> ports commit bit is alive and well though) thus I'm looking
> for a mentor. In addition I'm working on an ACER WMI/ACPI
> kld. One mentor would be preferred but two would be fine
> too.
 
 What are your plans regarding ipfilter? I remain unconvinced
 that it shoul
>> d b
 e in the base system. Perhaps you can work on it as a port?
>>> 
>>> The initial plan was to import IP Filter 5.1.2 into HEAD.
>>> darrenr@ hadn't done much with IPF while employed with Sun.
>>> Since then there has been some development that is long overdue
>>> for HEAD.
>>> 
>>> I'm not sure if I'd MFC it into 9 or not.
>>> 
>>> I did consider a port but given it would has to touch bits and
>>> pieces of the source tree (/usr/src), a port would be messy and
>>> the decision was made
>> 
>>> to work on importing it into base.
>>> 
 
 Why do you want to work on something that people have been
 trying to remov
>> e s
 ince 2005?
>>> 
>>> I and others have been using it in FreeBSD for over decade. For
>>> the longest
>> 
>>> of time we'd use a common set of rules across a FreeBSD and
>>> Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a
>>> local CVS repo). Interoperability with other systems which use
>>> IP Filter is a plus. If there's a maintainer, it only makes
>>> FreeBSD richer. Losing IP Filter would be a loss.
>>> 
>> 
>> 
>> If you're committed to maintaining IPFilter, that's great.
>> However, it can't be left to stagger along in a  zombie state
>> with nothing more than good intentio ns from well meaning people.
>> What is your timeline for getting it back into sha pe and
>> re-integrating yourself into the committer community?
> 
> I would think this would be my top priority right now. I'd like to
> see it at the latest level in HEAD. I would like to MFC to 9-STABLE
> at some point.
> 
> Given that IPF already lives in src/contrib and src/sys/contrib,
> would the change in License from Darren Reed's own not so BSD
> friendly IPF license to GPLv2 be of concern. I recall there was a
> lot of concern over IPF's license change at the time. (FreeBSD
> moved it to contrib while OpenBSD removed it completely and wrote
> PF -- I'm not sure what NetBSD did).

FYI, NetBSD has PF from OpenBSD:

http://www.netbsd.org/docs/network/pf.html

Also, they upgraded it to the latest GPL'ed sources recently (and
moved to a different directory):

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_with_tag=MAIN

Now they have their own packet filter, called NPF:

http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html

They have more choices now. :-)

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBAgAGBQJRbFjtAAoJECXpabHZMqHOSFkIAK72iLtzb1py01/A+SbX8ejn
hi5eh8ri6QQ2Kh4K96b/R5oHk5PoGNpc7xX7Kbp1wyJ2OrdNvAPnElwMDpPCjnRC
rKPXiS25Km9D1e18E2pLB4iTweb/AOf87bGRz6skm3Rq0D4XOX9dwRndj1vqRxmH
V/Rrdlzprx4EvDmgmfAfSZwGTGit6fVXqHHj5LtONURNKe4qAliVIdxB1vQFQBqB
BnHF1gN7tIJVCrn+4yKSVsv6vqRSXp5LOIRBw2ooURKEkkKqVIapboEU+pGitN4g
dbVZkoBol7V+LfqBBpsG7JH+OboUvdvWJ7hqeNtAV4YerBBBbePvx9D5iehmRUk=
=/mAG
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Gleb Smirnoff]

  Cy,

  good news that you volunteered to work on this!

On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
C> done much with IPF while employed with Sun. Since then there has been some 
C> development that is long overdue for HEAD.

The problem is that v5.1.2 is under GPL. I'm afraid we should update
to v4.1.34 only, and then stick to it. So the nearest TODO list
is smth like:

- update to v4.1.34
- cleanse old kernel APIs (timeout(9) at least)
- fix VIMAGE
- review open PRs (some might should be closed)
- since we do not expect more imports, may be cleanse non-FreeBSD stuff
  from there?
- maybe move it into sys/netpfil? Need to consult imp@ on that. License
  is very closed to BSD, but has some additions.

C> I'm not sure if I'd MFC it into 9 or not.

This is up to you, but be adviced that head already differs from stable/9,
for example network stack is entirely in network byte order. So merging
would require a lot of attention and testing.

C> I did consider a port but given it would has to touch bits and pieces of 
C> the source tree (/usr/src), a port would be messy and the decision was made 
C> to work on importing it into base.

Port isn't an option. IPFilter is too close to many kernel APIs, that
can change quickly.

-- 
Totus tuus, Glebius.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message <20130415195544.gy76...@freebsd.org>, Gleb Smirnoff writes:
>   Cy,
> 
>   good news that you volunteered to work on this!
> 
> On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
> C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't 
> C> done much with IPF while employed with Sun. Since then there has been some
>  
> C> development that is long overdue for HEAD.
> 
> The problem is that v5.1.2 is under GPL. I'm afraid we should update
> to v4.1.34 only, and then stick to it. So the nearest TODO list
> is smth like:
> 
> - update to v4.1.34
> - cleanse old kernel APIs (timeout(9) at least)
> - fix VIMAGE
> - review open PRs (some might should be closed)
> - since we do not expect more imports, may be cleanse non-FreeBSD stuff
>   from there?
> - maybe move it into sys/netpfil? Need to consult imp@ on that. License
>   is very closed to BSD, but has some additions.

A small step in the right direction is a good thing. I'll run the patches 
by you first.

The existing license isn't that BSD-friendly either, which is why it lives 
in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as 
Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. 
A person can always load it anyway.

> 
> C> I'm not sure if I'd MFC it into 9 or not.
> 
> This is up to you, but be adviced that head already differs from stable/9,
> for example network stack is entirely in network byte order. So merging
> would require a lot of attention and testing.
> 
> C> I did consider a port but given it would has to touch bits and pieces of 
> C> the source tree (/usr/src), a port would be messy and the decision was mad
> e 
> C> to work on importing it into base.
> 
> Port isn't an option. IPFilter is too close to many kernel APIs, that
> can change quickly.

Agreed. I looked at it a few months ago and determined that src is where it 
should be. (I put it aside, getting ACER WMI/ACPI working on my new Acer 
laptop was my priority at the time.)


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

It was pointed out to me that Darren Reed has changed licenses from his IP 
Filter license that's been in IPF since 2005 or so, when he joined Sun, to 
GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF 
already lives in src/contrib and src/sys/contrib due to the 2005 license 
change, would that be a problem? If it's OK then I'll maintain it in src. 
If not then a port is in order. Having said that, a port would be messy as 
IPF's own install scripts update src/sys/netinet, among other locations.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


In message , Scott Long 
writes:
> The desire to remove it stems from the inability to give it adequate engineer
> ing 
> service as the network stack evolves.  Simply taking it out of a kernel confi
> g file
> doesn't address that problem at all.  If it's going to stay in FreeBSD at all
> , it
> needs to be maintained.  This could be set about a fair amount of stuff in Fr
> eeBSD,
> but IPFilter stands out since there's a high rate of needed change happening 
> in
> the network stack, and it shouldn't be left to rot nor to be a stumbling bloc
> k for
> those changes.
> 
> Scott
> 
> On Apr 15, 2013, at 12:49 PM, "Sam Fourman Jr."  wrote:
> 
> > Thank you to those that have expressed interest in maintaining IP Filter..
> > 
> > My thoughts are, could we consider putting a option in the kernel config,
> > and leaving it off by default for GENERIC?
> > I think this is a acceptable compromise, considering some people wish for
> > it to be removed.
> > 
> > Sam Fourman Jr.
> > 
> > 
> > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrot
> e:
> > 
> >> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> >> writes:
> >>> 2013/04/15 9:55、Cy Schubert  
> >>> のメッセージ:
> >>> 
>  I've been planning on taking on IP Filter for quite some time.
>  Unfortunately I've left my src commit bit lapse (my ports commit bit is
>  alive and well though) thus I'm looking for a mentor. In addition I'm
>  working on an ACER WMI/ACPI kld. One mentor would be preferred but two
>  would be fine too.
> >>> 
> >>> What are your plans regarding ipfilter? I remain unconvinced that it
> >> should b
> >>> e in the base system. Perhaps you can work on it as a port?
> >> 
> >> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
> >> done much with IPF while employed with Sun. Since then there has been some
> >> development that is long overdue for HEAD.
> >> 
> >> I'm not sure if I'd MFC it into 9 or not.
> >> 
> >> I did consider a port but given it would has to touch bits and pieces of
> >> the source tree (/usr/src), a port would be messy and the decision was mad
> e
> >> to work on importing it into base.
> >> 
> >>> 
> >>> Why do you want to work on something that people have been trying to
> >> remove s
> >>> ince 2005?
> >> 
> >> I and others have been using it in FreeBSD for over decade. For the longes
> t
> >> of time we'd use a common set of rules across a FreeBSD and Solaris farm
> >> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).
> >> Interoperability with other systems which use IP Filter is a plus. If
> >> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would
> >> be a loss.
> >> 
> >> 
> >> --
> >> Cheers,
> >> Cy Schubert 
> >> FreeBSD UNIX: Web:  http://www.FreeBSD.org
> >> 
> >> 
> >> ___
> >> freebsd-curr...@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >> 
> > 
> > 
> > 
> > -- 
> > 
> > Sam Fourman Jr.
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
> 


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message <516c58ed.40...@freebsd.org>, Jung-uk Kim writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> > In message , Scott
> > Long writes:
> >> 
> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert
> >>  wrote:
> >> 
> >>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>,
> >>> Rui Paulo writes:
>  2013/04/15 9:55$B!"(BCy Schubert 
>  $B$N%a%C%;!<%8
> >> (B:
>  
> > I've been planning on taking on IP Filter for quite some
> > time. Unfortunately I've left my src commit bit lapse (my
> > ports commit bit is alive and well though) thus I'm looking
> > for a mentor. In addition I'm working on an ACER WMI/ACPI
> > kld. One mentor would be preferred but two would be fine
> > too.
>  
>  What are your plans regarding ipfilter? I remain unconvinced
>  that it shoul
> >> d b
>  e in the base system. Perhaps you can work on it as a port?
> >>> 
> >>> The initial plan was to import IP Filter 5.1.2 into HEAD.
> >>> darrenr@ hadn't done much with IPF while employed with Sun.
> >>> Since then there has been some development that is long overdue
> >>> for HEAD.
> >>> 
> >>> I'm not sure if I'd MFC it into 9 or not.
> >>> 
> >>> I did consider a port but given it would has to touch bits and
> >>> pieces of the source tree (/usr/src), a port would be messy and
> >>> the decision was made
> >> 
> >>> to work on importing it into base.
> >>> 
>  
>  Why do you want to work on something that people have been
>  trying to remov
> >> e s
>  ince 2005?
> >>> 
> >>> I and others have been using it in FreeBSD for over decade. For
> >>> the longest
> >> 
> >>> of time we'd use a common set of rules across a FreeBSD and
> >>> Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a
> >>> local CVS repo). Interoperability with other systems which use
> >>> IP Filter is a plus. If there's a maintainer, it only makes
> >>> FreeBSD richer. Losing IP Filter would be a loss.
> >>> 
> >> 
> >> 
> >> If you're committed to maintaining IPFilter, that's great.
> >> However, it can't be left to stagger along in a  zombie state
> >> with nothing more than good intentio ns from well meaning people.
> >> What is your timeline for getting it back into sha pe and
> >> re-integrating yourself into the committer community?
> > 
> > I would think this would be my top priority right now. I'd like to
> > see it at the latest level in HEAD. I would like to MFC to 9-STABLE
> > at some point.
> > 
> > Given that IPF already lives in src/contrib and src/sys/contrib,
> > would the change in License from Darren Reed's own not so BSD
> > friendly IPF license to GPLv2 be of concern. I recall there was a
> > lot of concern over IPF's license change at the time. (FreeBSD
> > moved it to contrib while OpenBSD removed it completely and wrote
> > PF -- I'm not sure what NetBSD did).
> 
> FYI, NetBSD has PF from OpenBSD:
> 
> http://www.netbsd.org/docs/network/pf.html
> 
> Also, they upgraded it to the latest GPL'ed sources recently (and
> moved to a different directory):
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_wi
> th_tag=MAIN
> 
> Now they have their own packet filter, called NPF:
> 
> http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html
> 
> They have more choices now. :-)

I'm always (or usually) one for more than fewer choices.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Gleb Smirnoff]

On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
c> However it would of been better if said person asked me as I already
c> offered to take it on but whatever.

More manpower - the better. Why can't you work together?


-- 
Totus tuus, Glebius.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Gleb Smirnoff]

On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote:
S> > Given that IPF already lives in src/contrib and src/sys/contrib, would the 
S> > change in License from Darren Reed's own not so BSD friendly IPF license 
to 
S> > GPLv2 be of concern. I recall there was a lot of concern over IPF's 
license 
S> > change at the time. (FreeBSD moved it to contrib while OpenBSD removed it 
S> > completely and wrote PF -- I'm not sure what NetBSD did).
S> 
S> I would assume that the license change would be OK, especially since the 
other
S> option is to remove it (or let it continue to rot and be an eyesore) but 
I'll defer to those like
S> Gleb and Rui with a more vested interest in it.

I'm not a licensing guru, so I can't tell whether GPL ipfilter can live in
src/ and if it can, where should it be. So I expect someone else to comment
on licensing.

My personal, biased towards BSD, wish, is to import only the last BSD-licensed
version, move it out of contrib to netpfil, remove zillions of compatibility
(towards other OSes) code and just maintain it. Maintaining means fixing bugs
and catching up on kernel changes.

We can ask Darren whether we can switch the license to pure BSD. Since he 
himself
switched the entire license to GPL, the insisting on the following clause
seems strange, and expect he won't insist on it.

> The licence and distribution terms for any publically available version or
> derivative of this code cannot be changed. i.e. this code cannot simply be
> copied, in part or in whole, and put under another distribution licence
> [including the GNU Public Licence.]

-- 
Totus tuus, Glebius.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: bge(4) sysctl tuneables -- a blast from the past.

[Sean Bruno]

> FreeBSD has too many knobs, but it would be nice if the bge defaults weren't
> so broken, so that they don't need overriding.
> 
> Bruce


So many knobs ... well here's more.  :-)

http://people.freebsd.org/~sbruno/bge_config_update.txt

At least this gets a man page update with references to manuals.

Sean


signature.asc
Description: This is a digitally signed message part

Re: bce(4) on the Dell PE 2950

[Doug Ambrisko]

On Fri, Apr 12, 2013 at 02:09:04PM -0700, Xin Li wrote:
| (Added David to Cc)
| 
| On 04/12/13 13:56, Sean Bruno wrote:
| > A note from cluster...@freebsd.org
| > 
| > It looks like there is some amount of instability or bugginess in
| > some of the Broadcom firmware(management) on the bce(4) chipeset
| > shipped on later generations of the Poweredge 2950 from Dell:
| > 
| > bce0: 
| > 
| > Specifically, we've seen that newer (9 and higher) have issues with
| > the doing initial setup and negotiation and that Dell did indeed
| > release newer firmware to fix the issues.  This requires a full
| > reboot into Linux (probably centos6) to get the update to execute.
| 
| I could be wrong but I *think* that the firmware is loaded on device
| initialization, so there may be a chance that the driver can do it
| when starting?  Additionally, maybe one can leverage the kernel
| firmware(9) framework so that the firmware can be more easily updated
| by user?

What we created at work was a tool to dump the NIC's "firmware" via the
BCE_DEBUG and BCE_NVRAM_WRITE_SUPPORT.  It's totally unsupported but
works well :-)  The usage is to flash it via Linux etc, boot FreeBSD
then dump the NVRAM contents.  Then use a "flashing" tool that
first saves the MAC address info, write the new image and then restore
the MAC address ... otherwise all of your NICs get the same MAC addresses!

If someone wants to make a decent tool out of it let me know.  It's
hacky but works.  This is why we added the BCE_NVRAM_WRITE_SUPPORT.
This means you need these options enabled in the kernel.  It's trivial
code based on public data.  I tossed it up at:
http://www.ambrisko.com/doug/bce_firmware.c
It needs a correct usage :-)  -r reads the NVRAM and -w writes it.
There is no error checking "flashing" the firmware since it isn't
done via the chip so if you write trash, then you break your NIC.
It's a starting point.  I put a header file up at:
http://www.ambrisko.com/doug/bce_struct.h

We've had issues with bce(4) devices since day one in which the BIOS,
BMC and NIC firmware had to be in some type of sync. or things
break.  For a while we actually had to use a cobbled together NIC
firmware image from a couple of releases of firmware.

Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfilter(4) needs maintainer

[Cy Schubert]

In message <20130415212826.ga76...@freebsd.org>, Gleb Smirnoff writes:
> On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
> c> However it would of been better if said person asked me as I already
> c> offered to take it on but whatever.

Sorry, I didn't see your posting. I had a permissions issue on my gateway 
which caused the loss of a few emails (still sorting through the list of 
bounces).

> 
> More manpower - the better. Why can't you work together?

I don't mind working with others. I know there's more than enough to keep 
everyone busy. My main goal is to make sure IPF doesn't disappear nor go 
into disrepair and to make sure it's well maintained. Let's work together.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/177878: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes on kern/177873

[linimon]

Synopsis: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes 
on kern/177873

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Apr 16 01:48:37 UTC 2013
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=177878
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: bge(4) sysctl tuneables -- a blast from the past.

[YongHyeon PYUN]

On Mon, Apr 15, 2013 at 03:35:56PM -0700, Sean Bruno wrote:
> 
> > FreeBSD has too many knobs, but it would be nice if the bge defaults weren't
> > so broken, so that they don't need overriding.
> > 
> > Bruce
> 
> 
> So many knobs ... well here's more.  :-)
> 
> http://people.freebsd.org/~sbruno/bge_config_update.txt
> 
> At least this gets a man page update with references to manuals.

You have to change BGE_STD_RX_RING_CNT to change number of RX
descriptors. It's hard-coded and it needs much more work to change
that. And I don't see any reason to modify that though(Max # of RX
descriptor is 512).

I think bge(4) touches minimal set of coalescing parameters but
publicly available bge(4) data sheet shows more coalescing
parameters. These parameters could be programmed with different
values(BDs & ticks) during interrupt. And some parameters are not
applicable to certain controllers. In addition, the allowed value
range for certain parameters vary on controller models. So I think
it's good idea to mention allowed value range for each parameters
as well as a warning that mentions possible connection lost caused
by wrongly programmed value(i.e. no RX interrupt for
bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0) 

It's common to see multiple instances of bge(4) in a box so I think
it would be better to implement them as sysctl tunables rather than
loader tunables(i.e. each controller may need different coalescing
parameters). Except hw.bge.allow_asf tunable, all others were
implemented to support multiple bge(4) instances. sysctl tunables
also allow dynamic change so you don't have to reboot your box
to change coalescing parameters.

> 
> Sean
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: bge(4) sysctl tuneables -- a blast from the past.

[Bruce Evans]

On Mon, 15 Apr 2013, Sean Bruno wrote:


FreeBSD has too many knobs, but it would be nice if the bge defaults weren't
so broken, so that they don't need overriding.


So many knobs ... well here's more.  :-)


Yes, adding more knobs would subtract value.


http://people.freebsd.org/~sbruno/bge_config_update.txt

At least this gets a man page update with references to manuals.


I didn't notice before that these are tunables and not sysctls.  That's
much more broken.  Actually tuning using them like I do with sysctls
would take ~1 reboots.  Tunables are bogus for anything that isn't
needed for booting.  Optimizations are needed for booting.

Technical bugs include:
- wrong defaults are claimed for *coal_ticks.  The defaults are 150, but
  are claimed to be 150 milliseconds.  These values are dimensionless,
  but since ticks take 1 microsecond each, 150 gives 150 microseconds,
  not 150 milliseconds.
- *coal_bds is claimed to be a count of packes (sic).  Actually, it is a
  count of buffer descriptors.  Small packets take 1 bd, but normal
  packets take 2, and jumbo packets many (?).  The best tuning may be
  depend on the average bds/packet.
- the new tunables are in the wrong namespace (hw instead of dev)
- the new tunables are too global (bge instead of bge.N)

There are only 2 bge tunables now, and they only have half of these bugs:
- hw.bge.allow_asf is in the wrong namespace
- hw.bge.allow_asf is too global
- dev.bge.%d.msi seems to be correct.
Both of the old tunables are needed for boot-time configuration.

Bruce
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"