Re: Un-obsolete'ing ipv6_enable

2010-04-03 Thread Doug Barton
Sorry it's taken me so long to get back to this, had a lot of other
pressing issues. Short version, I think you're taking the wrong approach
here.

Longer version, I'm going to be posting to -current shortly to ask for
opinions on what the defaults should be. My understanding from the last
go-round about this topic was clear, but I'd like to confirm it. I have
a new, more complete patch at
http://people.freebsd.org/~dougb/v6-enable.diff that I'll be writing up
for that post. I'd like to request that we all follow up on that post
when it happens so that the conversation can all happen in the same
location, and with a wider audience.

More details below.

On 03/11/10 20:59, David Horn wrote:
>  for brevity sake
>>> dh> Question 2) Assuming that people do desire consistency with allowing
>>> dh> for both a global, and a per-interface setting, do you agree with
>>> dh> having a global default for DHCPv4 (dhcpv4_default_enable), and for
>>> dh> IPv6 slaac/accept_rtadv  (ipv6-slaac_default_enable), and the
>>> dh> per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
>>> dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
>>> dh> meta configuration variable.

I'm not interested in dealing with v4 dhcp as part of this, I want to
focus on getting v6 back to reasonable defaults. You should of course
feel free to pursue your ideas about v4 dhcp separately.

>>>  I think the global configuration can be realized by setting something
>>>  like ifconfig_DEFAULT_="AUTO" instead of adding a new global
>>>  knobs.

Like I said, I'm hesitant to deal with v4 issues in this context. I'm
even more hesitant to deal with a global autoconf knob. The default v6
configuration is SLAAC, whereas in v4 there is not nearly as much
unanimity.

I actually look forward to a day when DHCPv6 is more common, and then
I'd like to revisit this topic.

> Historically (8.0-RELEASE and prior), there was a global rc.conf knob
> for ipv6 (ipv6_enable, default="NO") that performed several functions:
> 
> a)  Enabled (or disabled) ipv6 link-local address for every interface
> (auto_linklocal AND -ifdisabled)
> b)  Enabled (or disabled) ipv6 SLAAC by default for every interface by
> setting the global net.inet6.ip6.accept_rtadv=1 sysctl
> c)  inherently specified utilization of a ipv6 address () over an
> ipv4 address (A) when both were available from a dns query when using
> getaddrinfo()
> d)  Others I can not think of at the moment ?
> 
> As well, there has always been a per-interface variable for IPv4 dhcp
> (The pseudo-variable of "dhcp" on an ifconfig_IF rc.conf line), but no
> global knob.
> 
> Now, I propose two new global variables:  ipv6_slaac_default_enable,
> ipv4_dhcp_default_enable
> and several new/updated per-interface pseudo variables: auto, noauto,
> accept_rtadv, -accept_rtadv, slaac, noslaac, dhcp, nodhcp

I think (others may disagree) that this is too much complexity. I do
however agree with the idea of decoupling some of the functions that
ipv6_enable did previously. My patch doesn't change the current semantic
of ipv6_prefer, and adds the ability to do specify SLAAC, direct
configuration, and a NORTADV knob on a per-ipv6-interface basis.

> Changelist:

> 4) Misc changes/fixes:
>   Changed ifconfig_up() to use ipv6_autoconfif() rather than
> re-checking some values for itself,

I did my own pass on ifconfig_up(), but it ended up looking similar to
yours in some ways. In particular, I agree with this change and have
adopted it.

> and now allow
> ifconfig_em0_ipv6="inet6 2001:db8::1" to work with AND without
> user-specified "inet6", as it used to be implied, and most recently
> was required, and is now optional.

ifconfig_IF for v4 has always required "inet " I don't see any
reason to NOT require inet6 for ifconfig_IF_ipv6. Making things easier
for users is a good thing, but sometimes too many options make things
worse, not better. :)

>   Change ipv6_network_interfaces to default to "AUTO" just like
> network_interfaces (consistency is the theme)

This I agree with (on both counts), as I've stated previously.

More to come on -current.


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
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: bridged wlan/ether still the same

2010-04-03 Thread Stefan Bethke
Am 02.04.2010 um 09:45 schrieb Randy Bush:

> it's the bridge that worries me.  took me a while to make it work

It looks sane to me. Here's my slightly more convoluted setup (8-stable):

cloned_interfaces="bridge0 tap0 vlan1 vlan2 vlan3 gif0"
ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm vlan1"
ifconfig_bridge0_alias0="inet 44.128.65.1/26"
ifconfig_em0="up"
ifconfig_vlan1="vlandev em0 vlan 1"
ifconfig_vlan2="44.128.65.249/29 vlandev em0 vlan 2"
ifconfig_vlan3="172.23.54.1/24 vlandev em0 vlan 3"
ifconfig_tap0="up"

I've set bridge0's MAC address to avoid sillyness with a cheap desktop switch 
that would get confused on reboots.


HTH,
Stefan

-- 
Stefan BethkeFon +49 151 14070811



___
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"


Pfsense + freebsd+ avaya voip + ipsec

2010-04-03 Thread justino garcia
Avaya VOIP + PFSENSE + IPSEC not working.

Both ends were running 1.something, pfsense, and tunnel was ipsec vpn.
Branch office, could not get voip phone to work over the tunnel.

Prior to this, we had rv042 on both ends, and avaya voip phones worked.

Anyone gotten over ipsec, avaya voip phone to work.

Thanks
-- 
Justin
IT-TECH
___
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/140597: [netinet] [patch] implement Lost Retransmission Detection

2010-04-03 Thread linimon
Old Synopsis: [request] implement Lost Retransmission Detection
New Synopsis: [netinet] [patch] implement Lost Retransmission Detection

State-Changed-From-To: suspended->open
State-Changed-By: linimon
State-Changed-When: Sat Apr 3 17:54:12 UTC 2010
State-Changed-Why: 
New patch received.

http://www.freebsd.org/cgi/query-pr.cgi?pr=140597
___
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"