HEADS UP: Merging projects/ipfw to HEAD

2014-10-04 Thread Alexander V. Chernikov
Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (defaul

Re: HEADS UP: Merging projects/ipfw to HEAD

2014-10-04 Thread Marcelo Gondim
Excellent work! :) I really enjoyed the news. This new ipfwcome with FreeBSD 10.1 release? Cheers, Gondim On 04/10/2014 09:35, Alexander V. Chernikov wrote: Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are rela

Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic

2014-10-04 Thread Hiroki Sato
Hariprasad S wrote in <26e3f92ec670bd429db5cb319d773c137a8...@nice.asicdesigners.com>: ha> HI, ha> ha> Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. ha> Kernel used: FreeBSD HEAD r272051 ha> ha> Is anyone aware of this issue? Could you try r272547 o

remote host accepts loose source routed IP packets

2014-10-04 Thread el kalin
hi all… i'm setting up a freebsd 10 on aws (amazon) to be as secure as possible… i used openvas to scan it and pretty much everything is fine except this: "The remote host accepts loose source routed IP packets. The feature was designed for testing purpose. An attacker may use it to circumvent p

Re: remote host accepts loose source routed IP packets

2014-10-04 Thread el kalin
hi again… i have disabled the icmp pings… same result... currently: /etc/pf.conf: tcp_in = "{ www, https }" udp = "{ domain, ntp, snmp }" ping = "echoreq" set skip on lo scrub in antispoof for xn0 inet block in all pass out all keep state pass out inet proto udp from any to any port 33433 ><

Re: [PATCH] Only lock send buffer in sopoll() if needed

2014-10-04 Thread Rui Paulo
On Sep 30, 2014, at 11:00, John Baldwin wrote: > > Right now sopoll() always locks both socket buffers. The receive socket > buffer lock is always needed, but the send socket buffer lock is only needed > while polling for writing (there is a potential test of SBS_CANTSENDMORE > without the lo