Re: [PATCH] Only lock send buffer in sopoll() if needed
I'm not convinced that the race with SBS_CANTSENDMORE is OK, even though I
really want to write that it is. The risk here is that we miss an asynchronous
disconnect event, and that the thread then blocks even though an event is
pending, which is a nasty turn of events. We might want to dig about a bit and
see whether this case 'matters' -- e.g., that there are important cases where a
test for writability might need to catch SBS_CANTRCVMORE but SBS_CANTSENDMORE
is not simultaneously set.
Could you say a bit more about the performance benefits of this change -- is it
substantial? If so, we might need to add a new socket-buffer flag along the
lines of SB[RS]_DISCONNECTED that is 'broadcast' to both socket buffers on
certain events. Doing so might require rejiggering elsewhere by causing
additional locks to need to be held, possibly out of order.
Another thing that's worth pondering -- and it is a lot of work -- is finally
sorting out the conflation of SOCK_LOCK() and SOCKBUF_LOCK(&so_rcv). We have a
number of races in the socket state machine stemming from this conflation (due
to lockless reads along the lines of the one you are proposing, only against
so_state and friends). This is a non-trivial change, and it's not 100% clear to
me how to make it, so would require quite a bit of analysis. It might have the
effect of needing three non-trivial adjustments: (1) instantiating two new
locks per socket, one sleepable, one a mutex; (2) rejiggering a set of 'global'
socket properties out from under the receive lock, such as (but definitely not
limited to) so_state; (3) doing some socket-layer vs. protocol-layer
rejiggering so that protocol state machine is the 'primary' with event
notifications to the socket layer to update its state, as opposed to the
current world order where some state transitions are triggered by one layer, an
d some by the other. Although not pretty, you can see an example of a
resolution of a socket-protocol race in the current behaviour of solisten,
which used to drive the state machine from the socket layer, which conflicted
with protocol-layer checks; now, the protocol uses the socket layer as a
library to test (and later set) properties.
I don't think the issue you are looking at requires starting to dig into that
can of worms, but it is a long-standing problem in socket locking /
protocol-layer interaction that does need to get resolved in order to make the
behaviour of conditions like the one you are looking at 'more natural'.
Robert
On 30 Sep 2014, at 19: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 lock, but I think this might be ok). What do folks think?
>
> Index: uipc_socket.c
> ===
> --- uipc_socket.c (revision 272305)
> +++ uipc_socket.c (working copy)
> @@ -3003,7 +3003,12 @@ sopoll_generic(struct socket *so, int events, stru
> {
>int revents = 0;
>
> - SOCKBUF_LOCK(&so->so_snd);
> + if (events & (POLLOUT | POLLWRNORM))
> + SOCKBUF_LOCK(&so->so_snd);
> + /*
> +* The so_rcv lock doubles as SOCK_LOCK so it it is needed for
> +* all requests.
> +*/
>SOCKBUF_LOCK(&so->so_rcv);
>if (events & (POLLIN | POLLRDNORM))
>if (soreadabledata(so))
> @@ -3038,7 +3043,8 @@ sopoll_generic(struct socket *so, int events, stru
>}
>
>SOCKBUF_UNLOCK(&so->so_rcv);
> - SOCKBUF_UNLOCK(&so->so_snd);
> + if (events & (POLLOUT | POLLWRNORM))
> + SOCKBUF_UNLOCK(&so->so_snd);
>return (revents);
> }
>
> --
> John Baldwin
___
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: HEADS UP: Merging projects/ipfw to HEAD
On 04.10.2014 18:00, Marcelo Gondim wrote: Excellent work! :) I really enjoyed the news. This new ipfwcome with FreeBSD 10.1 release? Unfortunately, no. The plan is to commit it to HEAD and merge to 9/ and 10/ after 1 month. 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 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 (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 2.2.2.2/32 added: 1.1.1.1/32 added: 2.2.2.2/32 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 ipfw: Adding record failed: record already exists ^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 2.2.2.2/32 4.4.4.4/32 # ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 added(reverted): 3.3.3.3/32 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 ipfw: Adding record failed: record already exists ^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table "values" are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces (already merged). * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). * Probably some more less significant/forgotten features ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net
Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails
Hi, On Sat, 4 Oct 2014 21:32:47 -0400 Glen Barber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The first RC build of the 10.1-RELEASE release cycle is now available I installed this shortly after your e-mail came. The result was the same as with BETA3. If you remember, I have had the problem that the network inside jails stopped working after I installed BETA3. The upgrade to RC1 did not change anything. I took now the time to investigate a bit. The result is simple. All works as expected until lagg becomes enabled. If I remember right, BETA1 was my last working version. I have an em and an iwn interface in the machine. I can use both of them without any problems. As I can reproduce this problem 100%, it might be a good idea if I help you to find the source of the problem. My problem would be: how. If somebody could tell me where to start looking for the error, we might find it soon. Erich ___ 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: HEADS UP: Merging projects/ipfw to HEAD
On 10/4/14 20: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 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 (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 2.2.2.2/32 added: 1.1.1.1/32 added: 2.2.2.2/32 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 ipfw: Adding record failed: record already exists ^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 2.2.2.2/32 4.4.4.4/32 # ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 added(reverted): 3.3.3.3/32 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 ipfw: Adding record failed: record already exists ^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table "values" are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces (already merged). * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). * Probably some more less significant/forgotten features ___ 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" Hi, Good job, Waiting for your code :) Regards, Bycn82 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/l
Re: remote host accepts loose source routed IP packets
should is submit this as a bug?
On Sun, Oct 5, 2014 at 2:04 AM, el kalin wrote:
> 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 >< 33626 keep state
> pass proto udp to any port $dup
> ### pass inet proto icmp all icmp-type $ping keep state
> pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
> pass proto tcp to any port ssh
>
>
> # sysctl -a | grep sourceroute
> net.inet.ip.sourceroute: 0
> net.inet.ip.accept_sourceroute: 0
>
> in /etc/defaults/rc.conf:
>
> forward_sourceroute="NO"
> accept_sourceroute="NO"
>
>
> what am i missing? this is pretty important….
>
> thanks…..
>
>
>
> On Sat, Oct 4, 2014 at 11:46 PM, el kalin wrote:
>
>>
>> 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 poorly designed IP filtering
>> and exploit another flaw. However, it is not dangerous by itself.
>> Solution:
>> drop source routed packets on this host or on other ingress
>> routers or firewalls."
>>
>> there is no "other ingress routers or firewalls." except the AWS
>> "security group" which only has open ports 80, 443 and 22 and allICMP for
>> pinging...
>>
>> on the instance itself i have this already set up...
>>
>> in /etc/sysctl.conf i have:
>>
>> net.inet.ip.accept_sourceroute=0
>>
>> in /etc/derfaults/rc.conf i got:
>>
>> accept_sourceroute="NO"
>>
>>
>> # sysctl -a | grep accept_sourceroute
>> net.inet.ip.accept_sourceroute: 0
>>
>> i also have a pf enabled locally pretty much with the same ports as the
>> security group. can i use pf to drop those packets?
>>
>> how do i drop the source routed packets?
>> without this i can't pass a pci scan…
>>
>> thanks...
>>
>>
>>
>
___
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: remote host accepts loose source routed IP packets
On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: > should is submit this as a bug? Can you first try adding "set block-policy return" to pf.conf? OpenVAS might be assuming that a lack of response from your system to source routed packets is an acknowledgement that it is accepting them. Brandon Vincent ___ 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: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails
On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky wrote: > Hi, > > On Sat, 4 Oct 2014 21:32:47 -0400 > Glen Barber wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> The first RC build of the 10.1-RELEASE release cycle is now available > > I installed this shortly after your e-mail came. The result was the > same as with BETA3. If you remember, I have had the problem that the > network inside jails stopped working after I installed BETA3. The > upgrade to RC1 did not change anything. > > I took now the time to investigate a bit. The result is simple. All > works as expected until lagg becomes enabled. > > If I remember right, BETA1 was my last working version. > > I have an em and an iwn interface in the machine. I can use both of them > without any problems. > > As I can reproduce this problem 100%, it might be a good idea if I help > you to find the source of the problem. My problem would be: how. > > If somebody could tell me where to start looking for the error, we > might find it soon. > You'll need to identify where in the src caused the issue for you. To do this, you will need to identify where it was working (BETA1?). You would then have to step thru the sources until you find the point where it breaks. The easiest way would be to take the svn revision that is half way between BETA1 and BETA3, compile and install it and see if it works. You keep halving the result until you identify the commit that broke it. Once the offending commit is identified, email the list. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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: remote host accepts loose source routed IP packets
thanks brandon… but that didn't help…. i still get the same result… i guess i'd report this as a bug… On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent wrote: > On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: > > should is submit this as a bug? > > Can you first try adding "set block-policy return" to pf.conf? OpenVAS > might be assuming that a lack of response from your system to source > routed packets is an acknowledgement that it is accepting them. > > Brandon Vincent > ___ 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: remote host accepts loose source routed IP packets
ok.. this is getting a bit ridiculous… just did a brand new install of the freebsd 9.3 aim on amazon… with nothing installed on it and only ssh open i get the same result when scanning with openvas: "Summary: The remote host accepts loose source routed IP packets. The feature was designed for testing purpose. An attacker may use it to circumvent poorly designed IP filtering and exploit another flaw. However, it is not dangerous by itself. Solution: drop source routed packets on this host or on other ingress routers or firewalls.' and by default: # sysctl -a | grep accept_sourceroute net.inet.ip.accept_sourceroute: 0 thing is the other machine - the bsd 10 - was scanned with the sameopen vas setup and with a service called hackerguardian offered by a compony called comodo. they sell that service as a pci compliance scan. both machines are non compliant according to both the openvas scan and the hackerguardian one… i can't be done with this job if i can't pass the pci scan… i'd appreciate any help… thanks... now what? On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: > thanks brandon… but that didn't help…. > > i still get the same result… > > i guess i'd report this as a bug… > > > On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent > wrote: > >> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: >> > should is submit this as a bug? >> >> Can you first try adding "set block-policy return" to pf.conf? OpenVAS >> might be assuming that a lack of response from your system to source >> routed packets is an acknowledgement that it is accepting them. >> >> Brandon Vincent >> > > ___ 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: remote host accepts loose source routed IP packets
hmmm… could it be openvas?! just installed netbsd 6.1.4 aim i found on the aws community aims list… same thing.. just the possibility of both openvas and the hackarguardian service being both wrong is a bit too much of a coincidence for me… any thoughts? On Sun, Oct 5, 2014 at 3:21 PM, el kalin wrote: > ok.. this is getting a bit ridiculous… > > just did a brand new install of the freebsd 9.3 aim on amazon… > > with nothing installed on it and only ssh open i get the same result when > scanning with openvas: > > "Summary: > The remote host accepts loose source routed IP packets. > The feature was designed for testing purpose. > An attacker may use it to circumvent poorly designed IP filtering > and exploit another flaw. However, it is not dangerous by itself. > Solution: > drop source routed packets on this host or on other ingress > routers or firewalls.' > > and by default: > # sysctl -a | grep accept_sourceroute > net.inet.ip.accept_sourceroute: 0 > > thing is the other machine - the bsd 10 - was scanned with the sameopen > vas setup and with a service called hackerguardian offered by a compony > called comodo. they sell that service as a pci compliance scan. both > machines are non compliant according to both the openvas scan and the > hackerguardian one… > > i can't be done with this job if i can't pass the pci scan… > > i'd appreciate any help… > > thanks... > > > now what? > > > > > > > On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: > >> thanks brandon… but that didn't help…. >> >> i still get the same result… >> >> i guess i'd report this as a bug… >> >> >> On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent > > wrote: >> >>> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: >>> > should is submit this as a bug? >>> >>> Can you first try adding "set block-policy return" to pf.conf? OpenVAS >>> might be assuming that a lack of response from your system to source >>> routed packets is an acknowledgement that it is accepting them. >>> >>> Brandon Vincent >>> >> >> > ___ 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"
[patch] ipv6 prefix lifetime is not updated when address is updated through SIOCAIFADDR_IN6
Hi, I am running dhcpcd 6.4.3 on 11.0-CURRENT r271879M to get an ipv6 prefix from my ISP. The prefix is received with a lifetime of 86400 seconds. dhcpcd adds an address using the prefix with pltime and vltime of 86400. Before the address expires dhcpcd refreshes it but the interface route for the prefix is still deleted after 86400 seconds. dhcpcd uses SIOCAIFADDR_IN6 to update the address and the kernel doesn't update the prefix lifetime if the prefix already exists. Since ndpr_lastupdate is also not updated the prefix will expire. The issue doesn't happen when updating lifetime using ifconfig with pltime and vltime since ifconfig removes the address before adding it (each ifconfig invocation will reset the prefix lifetime). I created a patch to update the prefix lifetimes in SIOCAIFADDR_IN6 from the added address's lifetime. If there are two addresses with same prefix but different lifetimes it means the last one added will set the prefix lifetime. Another way will be to move the check in SIOCAIFADDR_IN6 to a new function nd6_prelist_update that will call nd6_prefix_lookup. If the prefix doesn't exist, call nd6_prelist_add. If it does exist, copy lifetimes (and ndpr_flags?). Before: # netstat -rn -f inet6 :::::/64 link#1U lan0 :::::1 link#1UHS lo0 ... After more than 86400 seconds: # ifconfig -L lan0 inet6 lan0: flags=8843 metric 0 mtu 1500 options=8000b inet6 fe80:::::%lan0 prefixlen 64 scopeid 0x1 inet6 :::::1 prefixlen 64 pltime 57257 vltime 57257 nd6 options=21 # ndp -p :::::/64 if=lan0 flags=L vltime=0, pltime=0, expired, ref=1 No advertising router ... # netstat -rn -f inet6 :::::1 link#1UHS lo0 ... Regards, Guy update_prefix_ltimes.patch Description: Binary data ___ 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"
Problem reports for freebsd-net@FreeBSD.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+- Needs MFC |183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. ___ 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: remote host accepts loose source routed IP packets
Hi, Can you please get a packet capture of what it's sending and what it's receiving? All accept_sourceroute does is prevent the stack from forwarding source routed packets. If it's destined locally then it's still accepted. You could try crafting an ipfw rule to filter out packets with these options set: from man ipfw: ipoptions spec Matches packets whose IPv4 header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. something like: 1 deny ip from any to any ipoptions ssrr,lsrr,rr 65000 allow ip from any to any -a On 5 October 2014 13:22, el kalin wrote: > hmmm… could it be openvas?! > > just installed netbsd 6.1.4 aim i found on the aws community aims list… > same thing.. > > just the possibility of both openvas and the hackarguardian service being > both wrong is a bit too much of a coincidence for me… > > any thoughts? > > > > > On Sun, Oct 5, 2014 at 3:21 PM, el kalin wrote: > >> ok.. this is getting a bit ridiculous… >> >> just did a brand new install of the freebsd 9.3 aim on amazon… >> >> with nothing installed on it and only ssh open i get the same result when >> scanning with openvas: >> >> "Summary: >> The remote host accepts loose source routed IP packets. >> The feature was designed for testing purpose. >> An attacker may use it to circumvent poorly designed IP filtering >> and exploit another flaw. However, it is not dangerous by itself. >> Solution: >> drop source routed packets on this host or on other ingress >> routers or firewalls.' >> >> and by default: >> # sysctl -a | grep accept_sourceroute >> net.inet.ip.accept_sourceroute: 0 >> >> thing is the other machine - the bsd 10 - was scanned with the sameopen >> vas setup and with a service called hackerguardian offered by a compony >> called comodo. they sell that service as a pci compliance scan. both >> machines are non compliant according to both the openvas scan and the >> hackerguardian one… >> >> i can't be done with this job if i can't pass the pci scan… >> >> i'd appreciate any help… >> >> thanks... >> >> >> now what? >> >> >> >> >> >> >> On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: >> >>> thanks brandon… but that didn't help…. >>> >>> i still get the same result… >>> >>> i guess i'd report this as a bug… >>> >>> >>> On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent >> > wrote: >>> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: > should is submit this as a bug? Can you first try adding "set block-policy return" to pf.conf? OpenVAS might be assuming that a lack of response from your system to source routed packets is an acknowledgement that it is accepting them. Brandon Vincent >>> >>> >> > ___ > 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: remote host accepts loose source routed IP packets
On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote: > All accept_sourceroute does is prevent the stack from forwarding > source routed packets. If it's destined locally then it's still > accepted. Out of curiosity, isn't "net.inet.ip.accept_sourceroute" supposed to reject incoming source routed packets? On 5 October 2014 13:22, el kalin wrote: > hmmm… could it be openvas?! OpenVAS is a fork of Nessus from when it was open source. HackerGuardian seems to use Nessus as the chief scanning engine. Brandon Vincent ___ 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: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails
Hi, On Sun, 5 Oct 2014 11:38:47 -0500 Scot Hetzel wrote: > On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky > wrote: > > On Sat, 4 Oct 2014 21:32:47 -0400 > > Glen Barber wrote: > > > >> The first RC build of the 10.1-RELEASE release cycle is now > >> available > > > > I installed this shortly after your e-mail came. The result was the > > same as with BETA3. If you remember, I have had the problem that the > > network inside jails stopped working after I installed BETA3. The > > upgrade to RC1 did not change anything. > > > You'll need to identify where in the src caused the issue for you. To > do this, you will need to identify where it was working (BETA1?). > You would then have to step thru the sources until you find the point > where it breaks. > > The easiest way would be to take the svn revision that is half way > between BETA1 and BETA3, compile and install it and see if it works. > You keep halving the result until you identify the commit that broke > it. > > Once the offending commit is identified, email the list. > this is what I wanted to avoid. A shame that -Dno_clean will not work here. It would save a lot of compile time without running the risk missing out some files. Anyway, I compile world and kernel just to make sure that the problem is caught. This will take some time. Erich ___ 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: HEADS UP: Merging projects/ipfw to HEAD
Hey Alexander, Very nice work, thank you so much to bring these stuff to us. Best Regards, 2014-10-04 20:35 GMT+08:00 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 (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level lookup, > batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet fields > at once. > * Ability to add different type of lookup algorithms for particular table > type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array and > flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port > algo flow:hash valtype skipto,fib >0:02 [2] zfscurr0# ipfw table fl2 info >+++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 >0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 >0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 >0:02 [2] zfscurr0# ipfw table fl2 list >+++ table(fl2), set(0) +++ >2a02:6b8::333,6,443 45000 >10.0.0.92,6,80 22000 >0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 > flow 'table(fl2)' > >ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >ipfw table mi_test add 10.0.0.8/30 >ipfw table mi_test add 2a02:6b8:b010::1/64 25 > ># ipfw table si add 1.1.1.1/32 2.2.2.2/32 >added: 1.1.1.1/32 >added: 2.2.2.2/32 ># ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 >exists: 2.2.2.2/32 2200 >added: 4.4.4.4/32 >ipfw: Adding record failed: record already exists >^ Returns error but keeps inserted items ># ipfw table si list >+++ table(si), set(0) +++ >1.1.1.1/32 >2.2.2.2/32 >4.4.4.4/32 ># ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 > >added(reverted): 3.3.3.3/32 >exists: 4.4.4.4/32 4400 >ignored: 5.5.5.5/32 >ipfw: Adding record failed: record already exists >^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & new > binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset in > old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something may > be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned IP_FW3-based > codes. > * The remaining opcodes were also converted to be able to eliminate all > older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time (eats > 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.o
Re: remote host accepts loose source routed IP packets
On Sun, Oct 5, 2014 at 6:24 PM, Brandon Vincent wrote: > On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote: > > All accept_sourceroute does is prevent the stack from forwarding > > source routed packets. If it's destined locally then it's still > > accepted. > > Out of curiosity, isn't "net.inet.ip.accept_sourceroute" supposed to > reject incoming source routed packets? that was my understanding too. as far a forwarding - have it off too: # sysctl -a | grep forwa kern.smp.forward_signal_enabled: 1 net.inet.ip.forwarding: 0 net.inet.ip.fastforwarding: 0 net.inet6.ip6.forwarding: 0 > > On 5 October 2014 13:22, el kalin wrote: > > hmmm… could it be openvas?! > > OpenVAS is a fork of Nessus from when it was open source. > HackerGuardian seems to use Nessus as the chief scanning engine. i'm aware of those. i used to use Nessus when it was open and did pre scanning for pci with it on freebsd 7 and 8 and everything was fine. now this is really mind boggling…. i can't imagine that both freebsd 9 an 10 and also netbsd 6 will have this "vulnerability" which according to the information that the hackerguardian (nessus?!) suggest to read points to links from 2002. unless it has to do with virtualization somehow. am i the first person ever to try to get pci compliant on bsd on aws?! i did report this as a false positive to hackerguardian on friday. haven't heard from them since. but i'm not holding my breath… > > Brandon Vincent > ___ 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: remote host accepts loose source routed IP packets
Hi, I'm just going off what I saw in the code. Maybe the code changed and the bug was introduced. I suggest: (a) use ipfw to filter them for now; and (b) file a PR (https://bugs.freebsd.org/submit/) so it's not forgotten. Thanks! -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"
