Re: Fwd: Re: [ipv6hackers] funny FreeBSD bug
On 07/28/2012 15:50, Bjoern A. Zeeb wrote: You can point the people ... I'm not pointing anyone at anything. I raised the issue here in case anyone here is interested in following up. Fernando already did. Doug -- Change is hard. ___ 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
Fwd: Re: [ipv6hackers] funny FreeBSD bug
FYI, this conversation is happening in the list below. I have no opinion regarding whether it is a bug or not, but I thought folks here might be interested. Doug Original Message Subject: Re: [ipv6hackers] funny FreeBSD bug Date: Thu, 26 Jul 2012 19:26:08 +0200 From: Marc Heuse m...@mh-sec.de Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com, Simon Perreault simon.perrea...@viagenie.ca Hi Simon, Am 26.07.2012 17:47, schrieb Simon Perreault: Le 2012-07-26 08:35, Marc Heuse a écrit : I found a funny bug in freebsd (9.0 with all updates): if you send an ICMP toobig message to it with a too low MTU size, FreeBSD will prepend any packet data with an one-shot fragment (or atomic fragment as Fernando calls it). Why do you think it's a bug? first it servs no use to add the fragmentation header if the packet is not fragmented. second I have not seen this behaviour in other OS, however I havent looked for it though. Seems like normal IPv6 behaviour to me. It's in the RFC... I cant remember having seen this in any rfc - do you have a pointer? Greets, Marc -- Marc Heuse www.mh-sec.de PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers ___ 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 10G forwarding performance @Intel
On 07/03/2012 23:29, Alexander V. Chernikov wrote: On 04.07.2012 01:29, Doug Barton wrote: Just curious ... what's the MTU on your FreeBSD box, and the Linux box? In this particular setup - 1500. You're probably meaning type of mbufs which are allocated by ixgbe driver? 1500 for both? And no, I'm not thinking of the mbufs directly, although that may be a side effect. I've seen cases on FreeBSD with em where setting the MTU to 9000 had unexpected (albeit pleasant) side effects on throughput vs. system load. Since it was working better I didn't take the time to find out why. However since you're obviously interested in finding out the nitty-gritty details (and thank you for that) you might want to give it a look, and a few test runs. hth, Doug -- This .signature sanitized for your protection ___ 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 10G forwarding performance @Intel
Just curious ... what's the MTU on your FreeBSD box, and the Linux box? (also, please don't cross-post to so many lists) :) Doug ___ 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 10G forwarding performance @Intel
On 07/03/2012 14:44, Luigi Rizzo wrote: On Tue, Jul 03, 2012 at 02:19:06PM -0700, Doug Barton wrote: Just curious ... what's the MTU on your FreeBSD box, and the Linux box? he is (correctly) using min-sized packets, and counting packets not bps. Yes, I know. That wasn't what I asked. -- This .signature sanitized for your protection ___ 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: Strong host model in IPv6?
So I guess I'll re-ask the question here: According to https://tools.ietf.org/html/rfc1122 that RFC has been updated quite a bit over the last 23 years. Have you followed that chain upwards to make sure that your concerns are still valid? Doug On 3/9/2012 3:26 PM, Alex Yong wrote: (Originally posted on freebsd-hackers@ - sorry) Hi all, I've been playing around with IPv6 networking on FreeBSD release 8.2 and found that there seems to be no strong incoming host model as specified in RFC 1122. I've spotted that in IPv4 there is the sysctl net.inet.ip.check_interface which defaults to set, but I've been unable to find any guarantees that strong host model is enforced in v6 in the comments or internet. According to the IPv6 Core Protocols Implementation book (3.7 Input processing: ip6_input() Function) the incoming network packet processing in ip6_input should use the routing table to look up whether packets are of relevance for an interface - but the code base has diverged significantly since then including vnets for jails which makes me wonder if this is a bug. However before going into the long grass and trying to fix it I thought I'd ask here to see if there's anything I could try first, if I'm making some horrific mistakes, or if somebody had come across this already (I had a quick look at svn but didn't see anything of concern). My recipe for reproducing is thus: One FreeBSD 8.2 machine (the box under test), with 2 network interfaces (interface 0 and interface 1). interface 0 is connected to a subnet with routes to the outside world on v4 and v6. Interface 1 is connected directly via ethernet cable to the interface of a testing machine, with v4 disabled and a static v6 address for an unroutable subnet via the other interface. A route is configured for this subnet out of interface 1 (to allow for communications with the testing machine). The testing machine (which happens to be running FreeBSD) has 2 network interfaces (interface A and B). Interface A is connected to the same subnet as interface 0 (this is for my administration prodding of the testing device), and interface B is directly connected to interface 1 on the machine under test. Interface B has a staticly configured IPv6 address that matches the subnet of interface 1. It has a route to allow traffic to flow this way, *and* a route configured to route traffic for the box under tests interface 0 IPv6 address via interface B. If I ping interface 0 from box 1, I get a response. To prove that the response isn't coming in via the other links I used tcpdump on that interface on the testing machine *and* the machine under test and showed packets entering and responses leaving those interfaces. My expectation here would be to see packets entering (as the bpf hook is below the IP layer) but see no response. I checked sysctl net.inet6.ip6.forwarding is set to 0 (on both machines). Many thanks for any help AlexY -- This .signature sanitized for your protection ___ 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: IPv6 and CARP
Looping in hrs@ since he's responsible for that area. On 03/03/2012 02:49, Attila Nagy wrote: Hi, On a recently built stable/9 I have these lines in rc.conf: ifconfig_em0_name=admin vlans_admin=pub create_args_pub=vlan 20 ifconfig_admin=inet 192.168.2.20 netmask 255.255.255.0 ifconfig_pub=inet 1.1.1.1 netmask 255.255.255.224 ifconfig_pub_ipv6=inet6 accept_rtadv ifconfig_carp0=vhid 1 pass beef 1.1.1.2/27 ifconfig_carp0_ipv6=inet6 2001::beef/64 When the machine boots up, it has every interfaces configured with the right addresses, except carp0, which has the IPv4, but no the IPv6 address. However if I specify: ifconfig carp0 inet6 2001::beef/64 carp0 gets the IPv6 address and I get carp0: 2 link states coalesced log entry. What is the problem with the above configuration, why doesn't carp0 get the IPv6 address during boot? -- This .signature sanitized for your protection ___ 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
Fwd: IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements
Looks like we are making progress here, but are not quite there yet. Original Message Subject: IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements Date: Wed, 22 Feb 2012 16:57:22 -0300 From: Fernando Gont fg...@si6networks.com Organization: SI6 Networks To: ipv6-...@lists.cluenet.de ipv6-...@lists.cluenet.de Folks, FYI, just posted: http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html It contains some test results regarding the implementation of RFC 5722 and draft-ietf-6man-ipv6-atomic-fragments. 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
Fwd: [ipv6hackers] rfc5722 implementation
Does anyone who knows more about this topic want to comment? If we're making progress in this area it would be nice to publicize it. Doug Original Message Subject: [ipv6hackers] rfc5722 implementation Date: Sat, 18 Feb 2012 12:50:13 +0100 From: Marc Heuse m...@mh-sec.de Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com hi folks, it seems that RFC 5722 (Handling of Overlapping IPv6 Fragments) is started to being implemented. I saw a patch for OpenBSD and it seems that Windows 7 got a silent patch for this. can anybody confirm? and are other OS affected too? greets, marc -- Marc Heuse www.mh-sec.de PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers ___ 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: allowing gif thru ipfw
If it's a hurricane electric tunnel don't you want protocol 41? On 01/31/2012 22:55, Eugene Grosbein wrote: 01.02.2012 11:36, Eric W. Bates пишет: Seems like a silly question; but how does one allow the packets composing a gif tunnel thru ipfw? I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: $fwcmd add 00140 allow ipencap from $he_tun to me $fwcmd add 00141 allow ipencap from me to $he_tun ($he_tun is an Hurricane Electric provider); but neither of them are hit; so that's wrong... tcpdump -i em_vlan5 -nnvvs0 ip proto 4 doesn't show any packets either... Try: tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. Eugene Grosbein ___ 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 -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Unnecessary sleep in network.subr: ipv6_up()
Looping in the author of that change ...
On 01/10/2012 02:24, Dennis Koegel wrote:
Cheers,
problem: Having a *lot* of IPv6 interfaces (Vlan interfaces in this case)
causes a huge and annoying delay time at system boot in 9.0R.
ipv6_up() in network.subr does this:
+ # wait for DAD
+ sleep `${SYSCTL_N} net.inet6.ip6.dad_count`
+ sleep 1
This happens for each and every interface, at a minimum (and default) of
two seconds per interface.
It seems the behaviour was introduced with r197139. Before this merge,
/etc/rc.d/network_ipv6 did the same sleeps, but only once for the whole
network startup.
I don't see why this should happen per interface, so I suggest the extra
sleeps are limited to once per network startup once again (or maybe
removed?).
--
You can observe a lot just by watching. -- Yogi Berra
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) 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: openbgpds not talking each other since 8.2-STABLE upgrade
On 01/03/2012 13:03, Hiroki Sato wrote: Okay, thank you for your report. I will take some time to fix TCP_MD5SIG support in openbgpd and inform you when another patch is ready. Any news on this? Not trying to be pushy, just wondering if I need to plan a test/change window. Thanks, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: openbgpds not talking each other since 8.2-STABLE upgrade
On 01/03/2012 10:03, Bjoern A. Zeeb wrote: On 3. Jan 2012, at 17:47 , Borja Marcos wrote: On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: Thanks for the link Nikolay. Borja, I assume it's the PR submission form that gave you trouble - sorry for that. Based on your report it sounds to me like the bug is in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option though I'd assume it's due to a difference in our (FreeBSD's) implementation of the option. Did you look at the OpenBSD/FreeBSD differences in your investigation? Both bird and quagga work as expected on FreeBSD. You can leave TCP_MD5 enabled in the kernel. If you specify password options for a BGP peer, it will enable TCP_MD5. Of course in FreeBSD it's a bit clumsy and you have to use setkey(8) to set the keys. But it works. The reason for setkey is just because the software (quagga, bird,...) didn't grow a proper key management integration on pfkey2. Would be easy. Might be needed soon anyway;-) Not having looked at the particular openbgpd patches in our ports tree I would almost expect there can only be a minor issue that it would stop to work for non-protected peers once MD5 support is present in the kernel and that should be easy to spot. Unfortunately Doug didn't say from where he updated to this December 8-STABLE to see if it could be the MFCs of the MD5 changes by Attilio could make OpenBGPd as in ports cranky? I mentioned December 29, sorry if that wasn't explicit enough, I didn't have the svn revision close to hand. Is r226260 the MFC that you're referring to? The log says, Skip TCP_SIGNATURE calculation for INP_TIMEWAIT case. If so, that happened in October so we're well past that in our version of -stable. I'll be working on the various suggestions (thanks everyone for them, most helpful!) and report back on what works. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: openbgpds not talking each other since 8.2-STABLE upgrade
On 01/03/2012 11:16, Bjoern A. Zeeb wrote: I was wondering from *where* you were updating, not to which revision. D'oh! Sorry ... the previous kernel was from stable/8 about 6 months ago. Well before Attilio's merge. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: openbgpds not talking each other since 8.2-STABLE upgrade
On 01/03/2012 11:06, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4f027bc0.1080...@freebsd.org: do We have a pair of physical FreeBSD systems configured as routers do designed to operate in an active/standby CARP configuration. Everything do used to work fine, but since an upgrade to 8.2-STABLE on December 29th do the two routers don't speak BGP to each other anymore. They both do function fine individually, and failover works. It is only the openbgpd do communication between them that's not flowing. Doug, does your kernel have TCP_SIGNATURE option? Yes. The patch[*] for net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG option on the listening sockets. [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff While this is an ugly hack and I will investigate more reasonable solution for that, I want to narrow down the cause first. Can anyone who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if this works or not? This patch works even if net.inet.tcp.signature_verify_input=1. If I turn that sysctl off on both sides they can talk to each other even without the patch. So that would definitely seem to indicate that the tcp_signature stuff is the source of the problem. What unfortunately did not work is configuring signatures on both sides. With the sysctl enabled, IPSEC set up on both hosts, and the tcp md5sig option in both bgpd.conf files, we got the same result as before, no communication between them. When -HUP'ing and/or restarting openbgpd with the tcp md5sig option enabled we get pfkey setup failed. So, working iBGP + no signatures is a good next step. iBGP + signatures would be an even better one. :) We're happy to test more patches, etc.; and thanks again to everyone who has responded so far. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: openbgpds not talking each other since 8.2-STABLE upgrade
On 01/03/2012 21:23, Nikolay Denev wrote: You are setting the keys with setkey for both directions of a single session, right? Yes. But thanks for asking. :) Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
openbgpds not talking each other since 8.2-STABLE upgrade
We have a pair of physical FreeBSD systems configured as routers designed to operate in an active/standby CARP configuration. Everything used to work fine, but since an upgrade to 8.2-STABLE on December 29th the two routers don't speak BGP to each other anymore. They both function fine individually, and failover works. It is only the openbgpd communication between them that's not flowing. They have OpenBGPd (openbgpd-4.9.20110612_1 from ports) installed. The active router takes BGP full route feeds from our peers and *should* feed it to the standby router via a direct connection (crossover cable between physical em2 ports). The relative bgpctl show reports: 10.0.0.2 12345 0 0 0 NeverActive or 10.0.0.2 12345 0 0 0 NeverConnect The bgp daemon for the active server periodically reports: bgpd[6773]: neighbor 10.0.0.2: socket error: Operation timed out There is not a connectivity problem between the two hosts; ssh for example works fine. Telnet'ing to the bgp port times out, even from the same machine. There is no firewall configured on that interface. TCP-MD5 is *not* configured on the bgpd side. We did try enabling it (properly) between the two machines via /etc/ipsec.conf to see if it would make a difference, but that also had no effect on this problem. We've tried tcpdump, and both machines can clearly see the TCP SYN and SYN-ACK setup packets flowing in both directions, but the ACK packet never happens. In netstat -an, the opening side gets: tcp4 0 0 10.0.0.2.16797 10.0.0.1.179 SYN_SENT and the receiving side gets: tcp4 0 0 10.0.0.1.179 10.0.0.2.16797SYN_RCVD Just to make sure pf can't possibly be affecting this, right at the top of pf.conf on both machines: ## Pass inter-router traffic pass quick on em2 from 10.0.0.2 to 10.0.0.1 pass quick on em2 from 10.0.0.1 to 10.0.0.2 This is sufficient because we can connect to bgpd with nc: $ nc -S 10.0.0.2 179 -??Z?^w?A?? Produces: $ netstat -an | fgrep 10.0.0.2 tcp4 0 0 10.0.0.1.25711 10.0.0.2.179 ESTABLISHED and $ netstat -an | fgrep 10.0.0.1 tcp4 0 0 10.0.0.2.179 10.0.0.1.25711 ESTABLISHED So this appears to be some sort of weird problem specific to openbgpd and the updated kernel. At this point I'm at a loss as to how to proceed, so any suggestions on how to fix, or even debug this will be greatly appreciated. Doug ___ 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 8 as an IPv6 router
On 12/13/2011 16:41, Hiroki Sato wrote: I do not think it is a good idea that the rtadvd daemon automatically splits prefixes shorter than 64 to ones with just 64. Which prefix should be advertised is one of things which a sysadmin must specify explicitly when it receives prefixes shorter than 64 via IA-PD or something, and it should match the actual subnet structure. A simple way to do so is to assign an address onto eth0, in his example, with desired /64 subnet prefix from the delegated (shorter) prefix, and run rtadvd with no configuration file. This is the expected scenario. A /60 address assigned on eth0 does not work as a default router address for multiple /64 subnets anyway... +1 There are some things that can be done automatically, this isn't one of them. The assign an address trick being a reasonable compromise. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: choosing distribution: FreeBSD
On 11/27/2011 7:13 AM, LinuxIsOne wrote: Hi, Well, I am basically a Windows convert, but very frankly saying that: I am new to the world of Linux. So I should use FreeBSD or something easier distribution in the Linux...? Or it is perfectly okay for a newbie to go with FreeBSD? FreeBSD isn't Linux, it's a different Unix-like operating system. If you want a basic, user-friendly version of Linux you probably want to look at Ubuntu. Good luck, Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: How to set interface description containing space in 8.x
On 10/22/2011 06:02, Jeremy Chadwick wrote: 3. Hand-hack /etc/network.subr to address this, which you will lose every time you run mergemaster I'm not sure why you'd say that. By design mergemaster checks the $FreeBSD Id string in the installed file and if it's the same as the one in the temproot then it deletes the temproot version and moves on. That behavior was primarily designed to accommodate configuration files, but it works just as well for everything else mergemaster deals with. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: No IPFW binary compat across versions ?
On 09/05/2011 17:18, Arnaud Lacombe wrote:
From my point of view, I should be able to run a FreeBSD 9.0 kernel
(when released) on top of a FreeBSD 5 userland without such issues.
Unfortunately your expectation is completely unrealistic. We do our best
to maintain backward compatibility but sometimes improvements require
breaking the KBI/ABI.
Also, we have never supported running a kernel from RELENG_N on anything
older than the latest version of RELENG_{N-1}.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) 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: ifconfig -alias with duplicate netmasks work?
On 08/22/2011 16:49, John wrote: Fellow Net'ers Debugging an nfs locking problem to a linux host, I accidently issued some ifconfig commands on the bsd server (9-current) and found that duplicate netmasks seem to work fine. For instance: bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether d4:85:64:66:2a:14 inet6 fe80::d685:64ff:fe66:2a14%bce0 prefixlen 64 scopeid 0x1 inet 10.24.99.127 netmask 0x broadcast 10.24.255.255 inet 10.24.99.128 netmask 0x broadcast 10.24.255.255 inet 10.24.99.126 netmask 0x broadcast 10.24.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active My experience on 8.x is that this will work for most things, but then fail in odd ways. You're still better off following the old advice of making the aliases for the same network have the all-1s netmask. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related
On 08/04/2011 22:59, Mattia Rossi wrote: Hi all, I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches and I'm distributing DNS servers that way now. Works fine, my box running CURRENT picks up the DNS servers and search domains and writes them into /etc/resolv.conf using the resolvconf script. The script anyhow overwrites my previous manual entries in /etc/resolv.conf which I need for my manual IPv4 setup... I think it's an easily fixable bug - haven't looked into it that close atm., but given that the resolvconf script is going to be rewritten/enhanced anyways, that's something to keep in mind. I think that manual entries should always be preferred. Check 'man resolvconf.conf' for information on name_servers_append. It would probably be nice if there was a _prepend equivalent. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: bce packet loss
On 07/11/2011 21:09, Charles Sprickman wrote: I've had it hammered into my brain over the years that for servers it's always best to set link speed and duplex manually at both ends to remove any possible issues with link negotiation. That hasn't been the right thing to do for at least 8 years or so, probably 10 or more. Yes, back in the 90's when all of this stuff was still new it was not uncommon to have autonegotiation issues, but any even sort of modern hardware (on either side of the link) will do better with auto than not. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: bce packet loss
On 07/11/2011 22:47, Charles Sprickman wrote: On Mon, 11 Jul 2011, Doug Barton wrote: On 07/11/2011 21:09, Charles Sprickman wrote: I've had it hammered into my brain over the years that for servers it's always best to set link speed and duplex manually at both ends to remove any possible issues with link negotiation. That hasn't been the right thing to do for at least 8 years or so, probably 10 or more. Yes, back in the 90's when all of this stuff was still new it was not uncommon to have autonegotiation issues, but any even sort of modern hardware (on either side of the link) will do better with auto than not. Some of us still work at places where the hardware is 10 years old, you know. :) True ... hence my careful specification of sort of modern. :) I do still see fixed setups in service provider handoffs - for example this colo, Level3 and Hurricane. Also all our metro ethernet stuff specifies a fixed configuration. From what I can gather, this seems to be the standard practice in that space, but then again you're supposed to be plugging into equipment that wouldn't have the buffer issues that a $450 Dell switch would have. Well one could also say that this sort of thing tends to result from the, There is a knob, I MUST twist it! syndrome. The rule I recall is never do autoneg on one side and fixed on the other, that more often than not will end up in a duplex mismatch. Yes, that's definitely true, and I should have mentioned it. Whatever you do on one side (auto/manual) you must also do on the other. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
carp for IPv6?
If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I get an error using either /64 or /128 as the mask: ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 ifconfig 2001:a:b:c::2/64: bad value (width too large) There are no examples for IPv6 in the man page, or the handbook; and I can't find any on line. I'm interested in configuration for the command line, and rc.conf. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: carp for IPv6?
On 07/04/2011 20:26, Michael Sinatra wrote: On 07/04/11 19:59, Doug Barton wrote: If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I get an error using either /64 or /128 as the mask: ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 ifconfig 2001:a:b:c::2/64: bad value (width too large) There are no examples for IPv6 in the man page, or the handbook; and I can't find any on line. I'm interested in configuration for the command line, and rc.conf. ifconfig_carp0=vhid 80 advskew 120 pass yomama 128.32.206.100/32 ipv6_ifconfig_carp0=2607:f140::::80/128 Works on 8.2-STABLE (June 7, 2011). Note that I cannot get carp to work properly without configuring an IPv4 address. Well that sucks. :-/ In the example you gave, how would you add the IPv6 address on the command line to an existing carp interface? 'ifconfig carp0 inet6 2607:f140::::80/128 alias' ?? Thanks for the response, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: carp for IPv6?
On 07/04/2011 21:20, Doug Barton wrote: On 07/04/2011 20:26, Michael Sinatra wrote: On 07/04/11 19:59, Doug Barton wrote: If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I get an error using either /64 or /128 as the mask: ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 ifconfig 2001:a:b:c::2/64: bad value (width too large) There are no examples for IPv6 in the man page, or the handbook; and I can't find any on line. I'm interested in configuration for the command line, and rc.conf. ifconfig_carp0=vhid 80 advskew 120 pass yomama 128.32.206.100/32 ipv6_ifconfig_carp0=2607:f140::::80/128 Works on 8.2-STABLE (June 7, 2011). Note that I cannot get carp to work properly without configuring an IPv4 address. I should point out that I was able to do the following: ifconfig carp2 *inet6* vhid 4 as above, and it worked in the sense that it configured the carp interface, but subsequently my IPv6 network went straight into the crapper. Hence, the statement that it won't work without an IPv4 address seems to be correct. This seems pretty sub-optimal given the world we currently live in ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: link-local needed w/static IP and gateway?
On 6/12/2011 3:30 PM, Charles Sprickman wrote: Can anyone help me understand what the relationship is between address resolution for the router I don't know what you mean by address resolution for the router. and link-local? Why is this required? Why can I ping other hosts on the subnet without enabling link-local? link-local is required for IPv6. The gateway address should be the link-local address, not the GUA. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Bridging + VLANS
On 05/21/2011 01:58, Matthew Bowman wrote: I have an uplink to my ISP on a 2 IP /30 network (1.1.1.0/30 in the diagram) No help for your actual problem, sorry. I just wanted to point out that 1/8 has been assigned by IANA to APNIC, so it should not be used as a substitute for RFC 1918 space. I'm assuming that you're just using it as a placeholder for the real assignment, however I would argue that even that is a bad idea since at minimum it's a bad example that others may draw poor conclusions from. Yours in pedantry, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proper way to setup IPv6 gateway on running node without reboot?
On 4/19/2011 10:18 AM, Lev Serebryakov wrote: Hello, Freebsd-net. I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. I've added to /etc/rc.conf: ipv6_enable=YES ipv6_ifconfig_em0=2001:470::1::1 prefixlen 64 ipv6_ifconfig_wlan0=2001:470::2::1 prefixlen 64 I hope that the here is a method of obfuscating the real addresses for this message? ipv6_defaultrouter=2001:470::::2 # uplink rtadvd_enable=YES rtadvd_interfaces=em0 wlan0 ipv6_gateway_enable=YES and run /etc/rc.d/network_ipv6 start /etc/rc.d/rtadvd start Interfaces em0 and wlan0 now have static addresses, but not link-local automatic ones, and it seems, that rtadvd doesn't announce anything. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proper way to setup IPv6 gateway on running node without reboot?
On 4/19/2011 11:39 AM, Lev Serebryakov wrote: Hello, Doug. You wrote 19 апреля 2011 г., 22:01:20: I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Does it mean, that, someone'll need to reboot for renumbering or adding new net segment (for example, I want to add one more WiFi SSID on this router in future, for public access)? I don't like this idea. Neither do I. :) I tried to improve it, but my changes were rejected. Ping hrs@ if you want to talk about your concerns, he's in charge of this stuff now. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. 8.2-STABLE Ok. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. ifconfig shows only one inet6 address for each (manually configured), and these nd6 flags: nd6 options=3PERFORMNUD,ACCEPT_RTADV Re-read what I wrote above. You've got to enable the link-local addresses for each interface. If that doesn't work, please paste full 'ifconfig' output into your next message. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
in6.c and panic: 0xc63dd000 must be migratable
Bjoern, We're seeing something very similar to the following with pf and IPv6: http://pastebin.com/AJzXmEWe I notice that you did some locking changes in r216022, could this be related? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: in6.c and panic: 0xc63dd000 must be migratable
On 04/08/2011 17:57, Bjoern A. Zeeb wrote: On Fri, 8 Apr 2011, Doug Barton wrote: Bjoern, We're seeing something very similar to the following with pf and IPv6: similar to what? We're seeing the must be migratable part of the panic, but nothing else. It would be helpful to include more data in your problem reports. What freebsd release? Yeah, sorry, not my best effort, but we were in the middle of a crisis. :) This is 8-stable (post 8.2-RELEASE) i386. Can you reproduce it? If so, how? Not at will, but it's happened twice now. panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 panic: 0xc63dd000 must be migratable cpuid = 1 This is the bit we see. Breaking to the debugger hasn't worked, and dumping is not an option (I inherited this system, trying to get it tuned up now). Depsite being in the subject that's just follow-up problems, though thinking about it (very wild guess) -- how many cores do you have and are you running with flowtable enabled? It's an SMP system, and yes, FLOWTABLE was in the kernel config. I took that out, and got the KDB options sorted out so that if it happens again hopefully I can get a stack trace. Thanks for the FLOWTABLE suggestion, wish I'd remembered that one myself. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: igb(4) won't start with igb0: Could not setup receive structures
On 3/30/2011 7:19 AM, Arnaud Lacombe wrote: Hi, On Wed, Mar 30, 2011 at 1:11 AM, Doug Bartondo...@freebsd.org wrote: The only things I've been able to get from Jack is We, at Intel, test em(4) at 256k nmbclusters. We do not have problem. If you have problem, raise nmbcluster.. 256k nmbcluster in my environment is not acceptable. Meanwhile, there are times where memory IS a constraint, and there are some things you can't do without more of it. yes, but the driver should not need a manual reset between the time resource are (heavily) scarce and the time it became available again. If you're facing that situation then obviously your system is constrained by hardware. It sounds like you have 3 choices: 1. Add more RAM 2. Use a different NIC 3. Set MTU lower I'm sorry to say that just because the software is free doesn't mean that we can guarantee that it will work on all hardware. Sometimes the physical limits of the hardware are what need to be changed. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: igb(4) won't start with igb0: Could not setup receive structures
On 3/30/2011 10:06 AM, Arnaud Lacombe wrote: No. We are taking about exceptional recoverable situation not handled by the software, it should not bring the complete system down. If you're swapping code has defect, you do not tell one to buy more RAM not to trigger the defective code, you fix the code. The situation is similar here. I understand that you believe the situations to be similar, however you may make your point more clearly if you share the patches you've developed with the list so that others can review/comment/etc. There is no need to cc me on further related messages. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: igb(4) won't start with igb0: Could not setup receive structures
It would probably be useful to document those tunables in the man page. It already has good sections for other tunables, so adding them should be easy. Doug On 03/29/2011 14:55, Jack Vogel wrote: Our validation group has a default postinstall process, every installed system gets those changes, and these mbuf pool sizes are in that set of changes. While I'm not opposed to system default settings changing its usually necessary to have local sys changes anyway, after all you don't get 9K jumbos without manually specifying them as well :) Regards, Jack On Tue, Mar 29, 2011 at 12:55 PM, Andrey Zonovand...@zonov.org wrote: Hi, New igb driver (and I think em too) is required too much 9k mbufs when it's been configured with mtu = 9000. On machine with 8 CPUs, driver is required 8192 9k mbufs, but by default there is only 6400 and network won't start. In previous versions for big mtu it was used 4k mbufs, by default there is 12800 and all worked fine. Maybe it's time to think about increasing default kern.maxusers/kern.ipc.nmbclusters? or use mp_ncpus for calculation these values? or just increase amount of mbuf_cluster/mbuf_jumbo_page/mbuf_jumbo_9k from that driver... I just want igb to work out-of-the-box. -- Andrey Zonov -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: igb(4) won't start with igb0: Could not setup receive structures
On 03/29/2011 22:07, Arnaud Lacombe wrote: ... or maintain internal changes to the driver to make it not that memory hungry/behave well under memory pressure, especially on system where memory_is_ a constraint. If you come up with patches, I'm sure everyone would like to see them. Meanwhile, there are times where memory IS a constraint, and there are some things you can't do without more of it. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
The tale of a TCP bug
http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
The tale of a TCP bug
http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 03/04/2011 16:21, Bjoern A. Zeeb wrote: That said I messed with the patch to avoid the two copies of the algorithms (so it will not be 4 soon). I know it compiles but I have yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs are ugly but we'll see those a lot more and need to figure out differnt ways to our code was written the last 10 years. http://people.freebsd.org/~bz/20110303-01-rfc6056.diff The patch also includes a bugfix for the ipv6 case wrt to un-binding on error. I'm now using this version of the patch with alg 4 and it's working fine. Thanks! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 03/04/2011 16:21, Bjoern A. Zeeb wrote: On Sun, 27 Feb 2011, Doug Barton wrote: As for default algorithm, is there any reason not to make it 4? Yes, it's expensive both computation time and stack wise. Last I put MD5ctxs on the stack I was told that it was previously avoided do to stack limits. I haven't seen complaints on lists about it but it possibly still true for small embedded. I'd also like to see a proper benchmark before switching the default on both state of the art and a soekris kind class of machine. We expect people doing embedded work to make all kinds of adjustments, I can't see any reason why this shouldn't be one of them. Modern general-purpose machines have more than enough resources to handle this. That said, maybe we need a knob like EMBEDDED to more easily handle some of these issues. I could see an default of alg 4 but something less computationally intensive ifdef EMBEDDED. That said I messed with the patch to avoid the two copies of the algorithms (so it will not be 4 soon). I know it compiles but I have yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs are ugly but we'll see those a lot more and need to figure out differnt ways to our code was written the last 10 years. http://people.freebsd.org/~bz/20110303-01-rfc6056.diff The patch also includes a bugfix for the ipv6 case wrt to un-binding on error. Cool! I'll try to test this new patch this weekend. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 02/27/2011 12:23, Fernando Gont wrote: On 08/02/2011 03:47 p.m., Doug Barton wrote: [catching up with e-mail] I've been up and running on this patch vs. r218391 for over 24 hours now, using algorithm 4 (as someone said is now the default in Linux) without any problems. I think Bjoern is better qualified than I to comment on the style of the patch, but it applies cleanly, and seems to run fine on both v4 and v6. Has this been commited to the tree, already? -- If so, what's the default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 02/27/2011 14:05, Bjoern A. Zeeb wrote: On Sun, 27 Feb 2011, Fernando Gont wrote: Hi, On 27/02/2011 05:38 p.m., Doug Barton wrote: Has this been commited to the tree, already? -- If so, what's the default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Not at all. Algorithm 4 (double-hash) is the best option, IMO. I am still planning to do it soon but there is another thing in the queue touching the pcb code, which are way harder to merge on conflicts than this, so I am waiting for that to happen first. Do you have a timeline? It's been weeks since you and I first spoke about this, and I really don't want this change to get lost in the shuffle, or worse, to be committed late in the pre-release cycle for 9.0 (which will mean it won't get adequate testing). The patch as posted applied cleanly to HEAD when I did it locally, and I can generate a clean patch from my local tree if needed. My vote is that because the port randomization patch is ready to go now, it should go in, and other work that isn't ready will have to adapt. But I'm willing to hold off for another week for a really good reason. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: mountd has resolving problems
On 2/17/2011 9:59 AM, Steven Hartland wrote: - Original Message - From: John Baldwin j...@freebsd.org Waiting for the default route to be pingable actually fixed a few other problems for us on 7 though as well (often ntpdate would not work on boot and now it works reliably, etc.) so we went with that route. Also fixed quite a few issues for us as well with services not reporting properly. Definitely something that should be considered as part of core I've already said that I plan to commit this once the releases are done. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 01/28/2011 06:33, Ivo Vachkov wrote: Hello, I would like to thank for the help and for the recommendations. I attach second version of the patch, I proposed earlier, including following changes: 1) All RFC6056 algorithms are implemented. 2) Both IPv4 and IPv6 stacks are modified to use the new port randomization code. 3) There are two variables that can be modified via sysctl: - net.inet.ip.portrange.rfc6056_algorithm - which allows the super user to choose one out of the five possible algorithms. - net.inet.ip.portrange.rfc6056_algorithm5_tradeoff - which allows the super user to modify the trade-off value used in algorithm 5. All values are explicitly checked for correctness before usage. Default values for those variables represent current/legacy port randomization algorithm and proposed values in the RFC itself. I haven't reviewed the patch in detail yet but I wanted to first thank you for taking on this work, and being so responsive to Fernando's request (which I agreed with, and you updated before I even had a chance to say so). :) My one comment so far is on the name of the sysctl's. There are 2 problems with sysctl/variable names that use an rfc title. The first is that they are not very descriptive to the 99.9% of users who are not familiar with that particular doc. The second is more esoteric, but if the rfc is subsequently updated or obsoleted we're stuck with either an anachronism or updating code (both of which have their potential areas of confusion). So in order to avoid this issue, and make it more consistent with the existing: net.inet.ip.portrange.randomtime net.inet.ip.portrange.randomcps net.inet.ip.portrange.randomized How does net.inet.ip.portrange.randomalg sound? I would also suggest that the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff so that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both values. But I won't quibble on that. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Proposed patch for Port Randomization modifications according to RFC6056
On 01/28/2011 11:57, Ivo Vachkov wrote: On Fri, Jan 28, 2011 at 9:00 PM, Doug Bartondo...@freebsd.org wrote: How does net.inet.ip.portrange.randomalg sound? I would also suggest that the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff so that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both values. But I won't quibble on that. :) I have no objections with this. Since this is my first attempt to contribute something back to the community I decided to see how it's done before. So I found: net.inet.tcp.rfc1323 net.inet.tcp.rfc3465 net.inet.tcp.rfc3390 net.inet.tcp.rfc3042 which probably led me in a wrong direction :) Yeah, I had actually intended to say something to the effect of there are plenty of unfortunate examples in the tree already so your doing it that way is totally understandable but I trimmed it. I understand your point and agree with it. However, my somewhat limited understanding of the sysctl internal organization is telling me that tree node does not support values. Am I wrong? You are likely correct. :) It's an inconvenient fact that often forget because that's not the sandbox that I usually play in. If my reasoning is correct, maybe I can create the sysctl variables with the following names: - net.inet.ip.portrange.randomalg (Tree Node) - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the selected algorithm) I would go with version to increase the visual distinctiveness. I searched the current tree and there doesn't seem to be a clear winner for how to portray this is the current N/M that is in use but version seems to have the most representatives. - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store the Algorithm 5 trade-off value) I'm assuming this is the N value mentioned in the RFC. If so, I commend you on your choice of tradeoff to represent it. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: tcp implementation source code
On 01/07/2011 14:35, Ivan Voras wrote: On 01/04/11 15:56, J. Hellenthal wrote: On 01/04/2011 04:46, Mickey Harvey wrote: I would like to know where I can find the source code for the TCP implementation so I can do some hacking on it. Have you looked through the repository at all ? http://svn.freebsd.org/ Specifically ... We generally try to avoid helping people with their CS 101 homework. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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
IPv6 + CARP + VLANs + pf == panic on 8-stable
[ Pardon the cross-post, feel free to follow up to just one list, I'm on both. ] Running a system on the latest 8-stable as a router we are seeing the following panic: http://pastebin.com/AJzXmEWe Kernel is as follows: include GENERIC ident ROUTER options SW_WATCHDOG options DEVICE_POLLING options TCP_SIGNATURE options IPSEC device crypto device cryptodev device carp device pf device pflog device pfsync options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options WITNESS options INVARIANTS options INVARIANT_SUPPORT options DDB options BREAK_TO_DEBUGGER Advice and suggestions welcome. A quick look at the diff between HEAD and RELENG_8 didn't show anything obvious to me in the areas affected, but that doesn't mean it isn't there. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Configuring for 1 static and 1 DHCP interface ?
While hacking dhclient-script gets you '1337 points, it's generally a better idea to use dhclient.conf to accomplish the same goals whenever possible. It's also a really bad idea to chflags /etc/resolv.conf (note, it's resolv.conf, not resolve.conf) because that can cause dhclient-script to loop. Perhaps the OP can re-post a description of the problem they are trying to solve at a higher level, rather than focusing on the solutions? Doug ___ 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: ipfw fwd doesn't handle ipv6 addresses
On 11/10/2010 14:42, gu...@bsdmail.org wrote: I'm running freebsd 7.2 and trying to find a way to forward a packet based on it's source address. The following command works fine for ipv4 addresses but fails for ipv6 addresses. ipfw add 101 fwd nextaddr ip from myaddr to any out This works fine if nextaddr and myaddr are ipv4 but fails to work if they are ipv6. Is this not yet supported or is there another way to accomplish the same thing ? You might want to take a look at the ipfw man page, I think what you want is me6, not myaddr. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: strange resolver behavour
On 10/13/2010 12:05 AM, Eugene Grosbein wrote: On 13.10.2010 01:39, Doug Barton wrote: I care about my resolver behavior. Ok, well, that's working as advertised, so no problems then. That's fine. And how about host(1)? It looks for MX record for synthetic domain names using suffixes from /etc/resolv.conf You said you wanted something that exercised the resolver, make up your mind. :) Hopefully it does not find but what if such names would exist and have MX records? host(1) would lie to me. No, it would act the way it's supposed to. If there is an answer that you should get, it will give it to you. If you want to debug something that isn't working the way you think it should, use dig. Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go 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: strange resolver behavour
On 10/14/2010 2:43 AM, Eugene Grosbein wrote: Is host(1) supposed to do lookups using suffixes from /etc/resolv.conf for FQDN with dot at the end? ... if only there were a document of some kind that described how the tool was supposed to work ... something like a manual ... :) Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go 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: strange resolver behavour
On 10/11/2010 8:32 PM, Eugene Grosbein wrote: On 11.10.2010 18:05, Hajimu UMEMOTO wrote: egrosbein Is it a bug in our resolver? I think no, host(1) links ISC's resolver, and it doesn't use libc's resolver. I suspect there is some problem in host(1) or ISC's resolver. Is there a command capable of looking up MX records and linked with libc resolver in base system? It's a pity if we have no diagnostic utility that behaves just like ordinary applications like MTA dealing with DNS... How am I supposed to debug suspected MTA behavior without such utility? Step 1, verify that your authoritative name servers have MX records in the first place. As it turns out, they don't. The proper tool to use to diagnose DNS problems is dig. It's more complex than the tools that are designed to just give you the answer, but if everything were working right to start with you wouldn't need to diagnose anything. See how that works? :) Good luck, Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go 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: strange resolver behavour
On 10/12/2010 5:34 AM, Eugene Grosbein wrote: On 12.10.2010 14:10, Doug Barton wrote: It's a pity if we have no diagnostic utility that behaves just like ordinary applications like MTA dealing with DNS... How am I supposed to debug suspected MTA behavior without such utility? Step 1, verify that your authoritative name servers have MX records in the first place. As it turns out, they don't. That is not my domain and I really don't care about its MX records/lame delegations/etc. Ah. Sorry for the misunderstanding. I care about my resolver behavior. Ok, well, that's working as advertised, so no problems then. Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go 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: Call for testers: RFC 5569 (6rd) support in stf(4)
I'm going to combine all of my responses into one message since it will be my last on the topic. It's pretty clear to me at this point that the code is going in, so I will make one last attempt to clarify my points in the hope that they are beneficial to anyone who is actually interested in learning. On 9/30/2010 4:38 PM, Bjoern A. Zeeb wrote: On Thu, 30 Sep 2010, Doug Barton wrote: Hey, In any case I didn't say that 6rd was not useful at all. What I tried to make the case for is that its utility is limited, both in the absolute sense and in the temporal sense; and that because of these limitations the benefits that adding the code bring are outweighed by the costs of maintaining it past what will likely be its useful lifetime. The maintainance costs are effectively pretty low, especially as it's coming with stf; it's a single line in a kernel config and not many more files but it will have great value to a lot of people the next years. From your statement above it's not clear to me that you have actually reviewed the diff. However your last statement is assuming the point that we're trying to discuss. You're basically saying it's good because it's good which isn't particularly helpful. My point about FreeBSD 9 is that if we add the 6rd code today, then release 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we will still be maintaining code that no one has any use for. Sorry if I wasn't clear. While I would like to live in that kind of world that by mid 10s all the tunneling, transition, .. technologies would be gone, ideally along with legacy IP, I guess you are massively underestimating this from the early adopters point of view; while for some of us things have happened and we are waiting for the world to catch up, for other folks things might not start within the another product lifecycle. I am sure we'll see a lot of different scenarios for quite some time. I would expect that we'll still be shipping that code in at least 12.x. I am not saying, nor have I ever said that the complete IPv4 - IPv6 transition will be complete in the next 5 years. What I am saying is that 6rd, as one particular transition mechanism, will have very limited value, and that the value of it is vastly exceeded by the short term instability and long term support issues that adding it will create. In contrast, the bit of my post that you snipped suggested that a better course of action would be to focus on the areas of our v6 stack that will be used for the lifetime of the protocol, like the performance penalty that currently exists for the v6 loopback device. I think that noone questions that this will need time as well and so do another 15 things on the IPv6 side but maybe someone is already working on it .. Hope is not a plan. :) On 10/1/2010 12:43 AM, Lars Eggert wrote: You're seriously underestimating the transition time needed for IPv6. Actually I think based on my extensive experience in this area I'm in a very good position to forecast what's going to happen, but as I've said several times now the overall time that the total v4-v6 transition will take is not relevant to my argument about this code. On 10/1/2010 2:09 AM, Hiroki Sato wrote: There is no trade-off between improving robustness/performance of the basic functionality and adding a new protocol in this case. The negative impact of adding 6rd is quite small if any, and we have nothing to lose even if 6rd will be useless some day. http://en.wikipedia.org/wiki/Opportunity_cost (seriously, you're part of the project leadership you really should develop an understanding of this topic). Short version, every second you spend doing something that has less overall utility for the project is a second that you cannot spend doing something that has more utility. You and gnn identified the performance penalty on the loopback interface months ago, and told me that it was a massive problem that prevented us from being able to make preferring IPv6 the default. Given that no matter what happens in IPv6 transition land we're always going to need the loopback address, would you not agree that solving that problem is more important than adding new flavors of STF? Doug ___ 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: Call for testers: RFC 5569 (6rd) support in stf(4)
On 9/30/2010 12:13 PM, Rui Paulo wrote: On 28 Sep 2010, at 23:27, Doug Barton wrote: On 9/22/2010 1:32 PM, Hiroki Sato wrote: | Hello, | | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? Well I don't want to be Mr. Negativity, but I'd like to suggest that adding this support is the wrong way to go. STF and teredo are transition mechanisms, and we're currently knee-deep (well maybe ankle-deep) in the deployment of IPv6. This is only going to pick up steam in the next few years given the impending run-out of the free /8s in the IANA pool. I disagree with you and I want to see this going in. Perhaps you could provide a little more information about the basis for your opinion, as I attempted to do for mine? If for no other reason than to help educate me on why I'm wrong? 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: Call for testers: RFC 5569 (6rd) support in stf(4)
On 9/30/2010 2:46 PM, Rui Paulo wrote: I really don't feel like discussion this ad nauseum as your last IPv6 thread, but 6rd is useful and your argument about the timeline for FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE in a week after this is committed to HEAD. Well I was actually trying to make a new start here and avoid discussing the history. In any case I didn't say that 6rd was not useful at all. What I tried to make the case for is that its utility is limited, both in the absolute sense and in the temporal sense; and that because of these limitations the benefits that adding the code bring are outweighed by the costs of maintaining it past what will likely be its useful lifetime. My point about FreeBSD 9 is that if we add the 6rd code today, then release 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we will still be maintaining code that no one has any use for. Sorry if I wasn't clear. In contrast, the bit of my post that you snipped suggested that a better course of action would be to focus on the areas of our v6 stack that will be used for the lifetime of the protocol, like the performance penalty that currently exists for the v6 loopback device. But that's really all I have to say, and I'd hate to ad nauseate you. 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: Call for testers: RFC 5569 (6rd) support in stf(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/22/2010 1:32 PM, Hiroki Sato wrote: | Hello, | | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? Well I don't want to be Mr. Negativity, but I'd like to suggest that adding this support is the wrong way to go. STF and teredo are transition mechanisms, and we're currently knee-deep (well maybe ankle-deep) in the deployment of IPv6. This is only going to pick up steam in the next few years given the impending run-out of the free /8s in the IANA pool. In my opinion we'd be much better off focusing on making our native IPv6 stack more robust rather than adding more transition protocols that will (with any kind of luck) be obsolete within the useful life of the 9.x branch. For example I seem to recall you identifying a performance penalty with the IPv6 loopback device vs. the IPv4 version. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMomu3AAoJEFzGhvEaGryE1hsH/iWx2smE8VC3akxNM8K8aCo5 ikGeSdpxRUVeu7Uz+fZ8RAIDkSPiD7qIIpGDFNJfur7KjojLJWS4twLCsXqmAQ62 kY4FsyWzogfYv+CnX1X7dmmYt7g1fNS3tzwq8cGS7HaQ74lP42W5dZBuqU8o9V2C 9Oq77LsmDNNnGYvpa9v/NgGxen6sm/ENC6Xb6cQ/5APd9inZqlJFjPwVQLvEFhf5 oI6GrP/jCprmhx7hDrnJ/OKvKp8+hxkzjRczRJ93ZYWWHvTSIhjkOaeCnTSwGmEa aFmdOVX+h3Y2rziNvrBhhzaDproGZXiyGUiZ/Lak/lypgbdpB7N3FO05p3hSaT8= =UjVm -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: Does not work resolving IPv6 addresses via IPv4 DNS-server
On Sun, 8 Aug 2010, Vladislav V. Prodan wrote: # host -6 2001:5c0:1000:b::599b 8.8.8.8 I think that there has been some fuzzy thinking on this thread. :) There is no way that the command above could possibly work. The -6 option to host means use IPv6 transport to make this request. The specification of 8.8.8.8 at the end of your line tells host to use the name server at that IPv4 address. So no possible way that could work. If you are trying to look up the PTR record for the address 2001:5c0:1000:b::599b just leave out the -6 and it will work fine. If you are trying to do something else, let us know and we'll try to help you with it. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Does not work resolving IPv6 addresses via IPv4 DNS-server
On Mon, 9 Aug 2010, Vladislav V. Prodan wrote: 09.08.2010 3:51, Doug Barton пишет: If you are trying to do something else, let us know and we'll try to help you with it. :) First, remove the output Invalid argument And instead of an error ;; connection timed out; no servers could be reached give something: 8.8.8.8 is not ipv6 address, make request without options -6 That's a request you'll want to make to ISC who actually writes the BIND software. I wouldn't make that modification to our local copy. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Patch for ip6_sprintf(), please review
Someone at work has been reading http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation :) This change follows the rules in that draft which will become and RFC as soon as it finishes winding its way through the process, so I am supportive of the change you are proposing. Doug On 5/15/2010 11:22 PM, Alfred Perlstein wrote: Hello, The following patch seems appropriate to apply to fix the kernel ip6_sprintf() function. What it is doing is ensuring that when we abbreviate addresses that the longest string of zeros is shortend, not the first run of zeros. Our internal commit log is: problem: Unification of IPv6 address representation fix: recommended format of text representing an IPv6 address is summarized as follows. 1. omit leading zeros 2. :: used to their maximum extent whenever possible 3. :: used where shortens address the most 4. :: used in the former part in case of a tie breaker 5. do not shorten one 16 bit 0 field 6. use lower case Present code in ip6_sprintf() is following rules 1,2,5,6. Adding fix for following other rules also.For following rules 3 and 4, finding out the index where to replace zero's with '::' and using that index. References: http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04.html Diff is attached in text format. ___ 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 -- ... 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: Workaround automatic re-loading of network drivers
Seems reasonable to me.
Doug
On 05/03/10 12:27, John Baldwin wrote:
While testing some changes with vlans and the new vlan_if syntax in rc.conf
I've noticed the following behavior:
ifconfig foo0.100 destroy
Will actually try to kldload the 'foo' driver. This can prove very non-
intuitive. In general I think we shouldn't try to kldload anything when
destroying an interface period. What I've done locally is to pass '-n' to
ifconfig when destroying an interface.
We should possibly fix some other bugs however. For example, ifmaybeload()
in
ifconfig should probably stop at the first non-digit it finds (e.g. .)
rather than trimming from the first digit on. Also, perhaps 'ifconfig foo
destroy' should imply -n without requiring it to be explicit.
I also moved the ifconfig destroy of wlan and vlan devices up before running
ifn_stop to prevent running 'ifconfig foo down' which would also reload the
driver due to the first bug in ifconfig.
Index: network.subr
===
--- network.subr (revision 207329)
+++ network.subr (working copy)
@@ -915,7 +915,7 @@
_list=
for ifn in ${cloned_interfaces}; do
- ifconfig ${ifn} destroy
+ ifconfig -n ${ifn} destroy
if [ $? -eq 0 ]; then
_list=${_list}${_prefix}${ifn}
[ -z $_prefix ] _prefix=' '
@@ -1000,10 +1000,10 @@
if ! ifexists $child; then
continue
fi
+ ifconfig -n $child destroy cfg=0
if autoif $child; then
ifn_stop $child
fi
- ifconfig $child destroy cfg=0
done
child_vlans=`get_if_var $ifn vlans_IF`
@@ -1014,10 +1014,10 @@
if ! ifexists $child; then
continue
fi
+ ifconfig -n $child destroy cfg=0
if autoif $child; then
ifn_stop $child
fi
- ifconfig $child destroy cfg=0
done
return ${cfg}
--
... 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: Fresh Build Not Taking IPv6 RA's?
On 04/23/10 11:54, Thomas Donnelly wrote: Hi, I have a few servers on a vlan which have all happily auto configured via RA, both FreeBSD and CentOS boxes. However, I freshly installed a FreeBSD 7 box, brought it to stable, and it wont auto configure. What are the versions of the FreeBSD boxes you have which are working? Did you run mergemaster, or similarly update /etc when you upgraded? What is different in the configuration between the working systems and the non-working? What version of FreeBSD are you installing? Does it work when you first install it before upgrading the OS? There is no inherent reason that it should not work, so you have more investigating to do. hth, 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: Un-obsolete'ing ipv6_enable
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: snip 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_proto=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 address 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: [ping6] freeaddrinfo()
On 03/13/10 04:25, Earl Lapus wrote: Hi, I was browsing through the ping6 code and I noticed that one particular call to getaddrinfo() didn't have a freeaddrinfo() pair. All calls to getaddrinfo() should have an equivalent freeaddrinfo(), right? Attached is a patch that tries-to-resolve this very small issue (applies cleanly on an 8.0p2 kernel source). Also, I'm not not 100% sure if that is the correct place to call freeaddrinfo() - I hope someone on the list would be kind enough to have look. For all such issues, please file a PR first so it doesn't get lost. When you get the PR confirmation back, feel free to alert the list to its existence. hth, 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: Un-obsolete'ing ipv6_enable
On 3/8/2010 5:43 AM, jhell wrote: On Sun, 7 Mar 2010 21:26, dougb@ wrote: Oops, missed one. Doug ;) Hi Doug everyone, Personally I think that ipv6_enable could be skipped(removed) all-in-all. Here is my reason: It seems needless to have if, the value of ipv6_network_interfaces could just be checked against to see if it is anything other than null. In the default case it is already set to auto and I propose removing ipv6_enable and change ipv6_network_interfaces to be null and if it is anything other then null ipv6 will be enabled in the same fashion it is now but less variables to have to specify in the long-run. I think your idea shows good creative thought, but I'm opposed to it. First, I like the fact that in the common case the list of network interfaces does not need to be configured for either protocol. It's too easy to make mistakes, and particularly for new installs this is a great feature. Second, the common way we have to enable or disable things with rc.d, including other networking features, is with the _enable variable. I think it's reasonable to return ipv6 to being consistent with this. 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: Apparent IPv6 bug
On 02/24/10 14:17, Li, Qing wrote: Please try this patch http://people.freebsd.org/~qingli/nd6.c.diff and let me know if it works out for you. Ok, been up for way more than 24 hours now, I would say that this bug is fixed. :) Thanks again for your quick reply. 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: Apparent IPv6 bug
On 02/24/10 14:17, Li, Qing wrote: Please try this patch http://people.freebsd.org/~qingli/nd6.c.diff and let me know if it works out for you. Thanks, -- Qing Thank YOU. :) Uptime is 12 hours so far, with fairly continuous (albeit light) IPv6 traffic and so far so good. I'll leave it up for as long as I can and report back. I'm pretty sure I've made it past 12 hours before with the previous kernel, but definitely never more than 24 so by tomorrow morning California time I should have a good idea if it's fixed. hth, 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: Apparent IPv6 bug
On 02/25/10 19:56, Steve Bertrand wrote: Do you want more v6 traffic thrown at the interface for testing? Thanks for the offer, but the load I have on it now is the same as what I had when I got the crashes, so I think it will either work, or it will not work. :) 19+ hours and counting 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
Apparent IPv6 bug
Howdy, I've had the following crash twice now when leaving my system up overnight: (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05f64af in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f6792 in panic (fmt=Variable fmt is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:579 #3 0xc05e7dfa in _mtx_lock_sleep (m=0xc5e69e28, tid=3314788032, opts=0, file=0xc08f2e6b /usr/local/src/sys/netinet6/in6.c, line=827) at /usr/local/src/sys/kern/kern_mutex.c:341 #4 0xc05e7ff1 in _mtx_lock_flags (m=0xc5e69e28, opts=0, file=0xc08f2e6b /usr/local/src/sys/netinet6/in6.c, line=827) at /usr/local/src/sys/kern/kern_mutex.c:203 #5 0xc077829d in in6_update_ifa (ifp=0xc5e69c00, ifra=0xc5606b70, ia=0xc8d41800, flags=0) at /usr/local/src/sys/netinet6/in6.c:827 #6 0xc07961ec in in6_tmpifadd (ia0=0xc5e90200, forcegen=0, delay=0) at /usr/local/src/sys/netinet6/nd6_rtr.c:2007 #7 0xc079009c in regen_tmpaddr (ia6=0xc5e9) at /usr/local/src/sys/netinet6/nd6.c:772 #8 0xc07916d5 in nd6_timer (arg=0x0) at /usr/local/src/sys/netinet6/nd6.c:666 #9 0xc06097ea in softclock (arg=0xc0987dc0) at /usr/local/src/sys/kern/kern_timeout.c:430 #10 0xc05cfd95 in intr_event_execute_handlers (p=0xc5938aa0, ie=0xc593d600) at /usr/local/src/sys/kern/kern_intr.c:1220 #11 0xc05d0b6f in ithread_loop (arg=0xc58ddb60) at /usr/local/src/sys/kern/kern_intr.c:1233 #12 0xc05cdb28 in fork_exit (callout=0xc05d0ad0 ithread_loop, arg=0xc58ddb60, frame=0xc5606d38) at /usr/local/src/sys/kern/kern_fork.c:843 #13 0xc0849af0 in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:270 (kgdb) The full core.txt.1 file is in my home dir on freefall. 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: How to enable IPv6 on a subset of interfaces
On Tue, 12 Jan 2010, Brett Lee wrote: Hello, Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an attempt to enable IPv6 on ONLY one of the systems two interfaces. Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled IPv6 only. From the KAME link below, and the files /etc/network.subr and /etc/defaults/rc.conf, am reading that ipv6_network_interface should work; however the following still results in em0 obtaining IPv6 addresses: http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt That link is prehistoric. While I haven't read it (past the date) I would not rely on it heavily. ifconfig_em0=DHCP ipv6_enable=YES ipv6_network_interface=bge0 There is no such option in rc.conf. Spelling counts. :) ipv6_network_interfaces=bge0 You want to include lo0 in this list. You haven't specified what IPv6 addresses you're seeing on em0 that you don't want to see. At minimum you will see the link local address (it starts with fe80::) but that is simply an artifact of having IPv6 in the kernel, and is not avoidable. It also isn't going to hurt anything. It would also be helpful if you could be more specific about what your goals are. In other words, why do you want IPv6 on only one interface? If we had more information we could help you better. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: ping6 and a do-not-fragment option
Richard A Steenbergen wrote: Hi, I just noticed, while trying to do a little debugging, that ping6 doesn't seem to have a way to specify do not fragment like ping does for IPv4. Obviously the way this is implemented has been changed, since there is no longer a DF-bit in IPv6, but it looks like there is already an IPV6_DONTFRAG setsockopt() available for exactly this purpose. It looks like IPV6_DONTFRAG got added at a later date (from RFC3542), perhaps after ping6 was initially written. It seems like the correct fix would be to add a cli option to ping6 (perhaps 'D', since it's available and matches the command in ping) to call this setsockopt() and implement a do not fragment option. Sounds good, we look forward to reviewing your patches. :) Doug -- 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: [CFR] unified rc.firewall
Hajimu UMEMOTO wrote: Hi, The ipfw and ip6fw were unified into ipfw2, now. But, we still have rc.firewall and rc.firewall6. However, there are conflicts with each other, and it confuses the users, IMHO. So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete rc.firewall6 and rc.d/ip6fw. Please review the attached patch. If there is no objection, I'll commit it in next weekend. Overall I think this is good, and I'm definitely in favor of more integration of IPv6 into the mainstream rather than something that is glued on. A few comments: In rc.firewall you seem to have copied afexists() from network.subr. Is there a reason that you did not simply source that file? That would be the preferred method. Also in that file you call if afexists inet6 quite a few times. My preference from a performance standpoint would be to call it once, perhaps in a start_precmd then cache the value. And of course, you have regression tested this thoroughly, yes? :) Please include scenarios where there is no INET6 in the kernel as well. hth, Doug -- 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: bridging vs wifi, proxy arp broken on 8.0 rc?
Juergen Lock wrote: The problem with bridging and wifi is that on wifi you usually can use only a single mac address... Ok, I'm not heartbroken if it won't work, but it would be nice if the wiki were updated so that no one else wastes time on it like I did last night. Doug -- 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: OSPF and ifconfig -alias problem
Leonardo Reginin wrote: Hello fellows. I have a FreeBSD 5.1 ( it's old, I know ) It's well past old. You're unlikely to get any help on this since 5.x is EOL and 5.1 isn't even close to the latest release on that branch. I would be happy to be proven wrong though. Doug -- 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: WPI panic
Lawrence Stewart wrote: Doug Barton wrote: I cc'ed those who seem to have put the most/recent effort into sys/dev/wpi. Is there any objection to turning off WPI_DEBUG by default? it creates a lot of spam that the average user doesn't need. I use my 3945abg every day and haven't had any problems with it for ages so I think it's safe to say we're out of the period were debug by default is needed? Doug, have you ever experienced the issue with your 3945 card that I reported here: http://lists.freebsd.org/pipermail/freebsd-net/2009-October/023348.html I'm guessing you haven't by your comment about lack of problems. No, I have not had those problems at all. I routinely associate with both WPA and WPA2 routers, as well as open routers at coffee shops and such. Do you run with INVARIANTS in your kernel? Yes, and up till recently I've been running with witness as well. Wish I could be more help, Doug -- 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
Can we turn off WPI_DEBUG
I cc'ed those who seem to have put the most/recent effort into sys/dev/wpi. Is there any objection to turning off WPI_DEBUG by default? it creates a lot of spam that the average user doesn't need. I use my 3945abg every day and haven't had any problems with it for ages so I think it's safe to say we're out of the period were debug by default is needed? Doug -- 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: Wacky DHCP values that work in windows but not in FreeBSD
I'm adding Brooks to the cc list since he is mr. dhcp lately. :) David Horn wrote: On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton do...@freebsd.org wrote: David Horn wrote: Without seeing the actual tcpdump of the dhcp packets, I would guess that this is the Classless Static Route option in DHCPv4 (option 121). Ok, I will give the tcpdump option a go as soon as I have a chance. I finally had a chance to look at this again (with your revised tcpdump command line from another mail of yours) and I think you're right. The log (http://people.freebsd.org/~dougb/tcpdump.log) definitely mentions Classless-Static-Route. This was with the stock dhclient in -current. I also tried ISC's 4.1.1b3 just to be sure, and that did not work either. I also tried the various incarnations of route that were suggested on this thread, including all 4 combinations with/without -iface and -hopcount, and none of that worked either. Quick recap, I got the following from dhcp: Your-IP 76.244.161.xxx Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 151.164.184.xxx Now what DID work was something I tried on a whim. Actually two things worked, 'route add default 76.244.161.1' and (after rebooting) 'route add default 76.244.0.1'. With either of those I could reach things both inside the network (like the name server) and out in the wide world. I have no idea WHY those worked, I suspect that Mike Smith was right and there is some sort of proxy-arp going on, but I'm far from a networking expert. I'll leave the tcpdump log up for a while if y'all think it's useful. I can also test patches for this if someone comes up with a fix. Doug Meanwhile, if this is in fact the case how would we make it work in FreeBSD? Is there a newer version of DHCP that handles this properly? I thought that dhclient originated from ISC, but looking at the 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see option 121 handling in dhclient. The freebsd copy of both dhclient.c, and /sbin/dhclient-script there is code for handling this option. I guess the FreeBSD version split from the ISC version at some point, and option 121 handling was added (2+ years ago). As far as fixing/debugging, it all depends on the exact dhcp options and values. It might just be a tweak to /sbin/dhclient-script, or it may be more complicated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c Revision 1.21: download - view: text, markup, annotated - select for diffs Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 Branch point for: RELENG_7 Diff to: previous 1.20: preferred, colored Changes since revision 1.20: +68 -0 lines Implement RFC3442, the Classless Static Route option. The original DHCP specification includes a route option but it supports only class-based routes. RFC3442 adds support for specifying the netmask width for each static route. A variable length encoding is used to minimize the size of this option. PR: bin/99534 Submitted by: Andrey V. Elsukov bu7c...@yandex.ru Reviewed by:brooks ---Dave H -- 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
Wacky DHCP values that work in windows but not in FreeBSD
Howdy, I usually have a wireless router connected directly to the ATT/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were correct, and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx DHCP Server . . . . . . . . . . . : 192.168.1.xxx DNS Servers . . . . . . . . . . . : 192.168.1.xxx Can anyone tell me how they managed to get this to work in Windows, and suggest where to look to get it working in FreeBSD? Doug -- 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: Wacky DHCP values that work in windows but not in FreeBSD
Michael K. Smith - Adhost wrote: -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Julian Elischer Sent: Monday, October 12, 2009 4:00 PM To: Doug Barton Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD Doug Barton wrote: Howdy, I usually have a wireless router connected directly to the ATT/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were correct, and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx huh? only way this could work would be if it was marked as point to point I think.. That could be a primary IP address on an interface on which your 76 address is a sub interface. Can you specify what you mean by 'that'? The interface will do proxy-arp when a traffic request comes in. Or something else! I'm not sure if this will work, but you could actually hard code your default gateway with a -hopcount 2 (or higher) and see if that works. I've not tried it on a live machine. Something like route add default 151.164.184.xxx -hopcount 5. You may have to delete the DHCP-assigned entry first. Ah, I didn't know about -hopcount, thanks. There was no default route installed at all when I booted. I tried 'route add default 151...' even though I was sure it wouldn't work, and I was not disappointed. Doug -- 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: Wacky DHCP values that work in windows but not in FreeBSD
security wrote: ATT uses PPPoE on their modems. Did your router have any special PPPoE settings? It's a two-piece thing, their modem and my wireless router. The wireless router and windows know what to do with the info they are handed from the modem, FreeBSD doesn't. Sorry if I wasn't clear, Doug -- 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: host(1) coredumps
vol...@vwsoft.com wrote:
On 09/13/09 06:27, Eugene Grosbein wrote:
Hi!
For 8.0-BETA3:
% host -l grosbein.pp.ru. ns2.rucable.net.
; Transfer failed.
/usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
REQUIREsock) != ((void *)0)) (((const isc__magic_t *)(sock))-magic
== ((('I') 24 | ('O') 16 | ('i') 8 | ('o')) failed.
zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net.
Shoud I send PR?
Eugene Grosbein
Eugene,
the attached patch works around the error for me. As this is contributed
code, it should be fixed upstream (no need to file a PR).
Can Eugene, Volker, and anyone else affected by this please try this
very-lightly-modified version of the patch and confirm that it works?
If so, I will get this in ASAP.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Index: dighost.c
===
--- dighost.c (revision 198000)
+++ dighost.c (working copy)
@@ -2604,10 +2604,12 @@
if (sevent-result == ISC_R_CANCELED) {
debug(in cancel handler);
- isc_socket_detach(query-sock);
- sockcount--;
- INSIST(sockcount = 0);
- debug(sockcount=%d, sockcount);
+ if (query-sock != NULL) {
+ isc_socket_detach(query-sock);
+ sockcount--;
+ INSIST(sockcount = 0);
+ debug(sockcount=%d, sockcount);
+ }
query-waiting_connect = ISC_FALSE;
isc_event_free(event);
l = query-lookup;
signature.asc
Description: OpenPGP digital signature
Re: Wacky DHCP values that work in windows but not in FreeBSD
David Horn wrote: Without seeing the actual tcpdump of the dhcp packets, I would guess that this is the Classless Static Route option in DHCPv4 (option 121). Ok, I will give the tcpdump option a go as soon as I have a chance. Meanwhile, if this is in fact the case how would we make it work in FreeBSD? Is there a newer version of DHCP that handles this properly? Doug -- 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: host(1) coredumps
Mikolaj Golub wrote: BTW, we have already had the pr about this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/138061 IMO it would be nice to add the patch there. Normally that would be a good idea, but I've just adopted the PR and sent a link to it and the patch to the bind-users list. Assuming we get a thumbs up I'll take care of adding it to the port and the base. Thanks, Doug -- 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: Why not work whois -6 ?
Vladislav V. Prodan wrote: FreeBSD 8.0-BETA4 amd64 # whois -6 2a01:d0::1 whois: connect(): Connection refused In man whois written: -6 Use the IPv6 Resource Center (6bone) database. It contains net- work names and addresses for the IPv6 network. There are ideas on how to define membership of a particular block of ipv6? I just committed r197725 in HEAD to deal with this, thanks for the reminder. I will MFC the change as soon as it's possible to do so. Doug -- This .signature sanitized for your protection ___ 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: conf/132179: [patch] /etc/network.subr: ipv6 rtsol on incorrect wlan interface
David Horn wrote: Please close this bug (conf/132179) as fixed. SVN r195029 Cool, I fixed a PR without even knowing it. :) Thanks for letting us know it's fixed, and sorry I missed the PR first time around. Doug -- This .signature sanitized for your protection ___ 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: WLAN performance Windows/XP ./. FreeBSD 8-CURRENT
Matthias Apitz wrote: Hello, I am wondering what could cause the following WLAN performance diff between a XP and 8-CURRENT laptop, sitting side by side and connected to the same AP: OS XP 8-CURRENT NIC Intel 3945ABGAtheros 5424/2424 Ping 6ms 116ms downstream 9.05Mbit/s 6.58Mbit/s upstream 6.58Mbit/s 4.55Mbit/s measured with http://www.speedtest.net/ against the same remote server at the same time... Any ideas? Since you asked the question in the most generic way possible, here are some generic answers: 1. Different hardware a. Different wlan cards (as you pointed out) b. Different laptops c. Different harddrives 2. Different speedtests (java, flash, etc.) 3. Different protocols (802.11[abg]) 4. Different settings on the wlan cards (beacons, etc.) 5. Some sort of preference settings (user-visible or not) on the AP that prefers one card over the other In other words, you haven't given us nearly enough information to determine anything useful. hope this helps, Doug -- This .signature sanitized for your protection ___ 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: NTP - default /etc/ntp.conf
Frank Behrens wrote: Edwin Groothuis ed...@freebsd.org wrote on 5 Jun 2009 22:44: After pondering at conf/58595, I came with this text. The ntpd is not enabled by default, so the fact that the servers are commented out should not be an issue. ... +# server pool.ntp.org +# server pool.ntp.org +# server pool.ntp.org Isn't it better to use different entries? server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org To be sure that the IP addresses are different. See http://www.pool.ntp.org/en/use.html I agree with this suggestion, as well as the others about adding the default restrictions and the fallback local clock. Bruce is right about the ntp.drift file name, however we already have existing stuff that mentions ntpd.drift, and since it's specified on the command line in rc.conf the problems of what it says in the code are bypassed. OTOH, we should use ntp.conf (no d) since that is what is referenced in the man page for ntpd, and the man page for the conf file is ntp.conf. (It's currently wrong in the Makefile in your patch.) One more thing, it was said some time ago that due to a quirk in how ntpd works on our system that adding the following to the server line makes it work more efficiently: server foo iburst maxpoll 9 If someone smarter than me could confirm that it would be great. :) hth, Doug -- This .signature sanitized for your protection ___ 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: change in ifconfig out put for wlan devices on -CURRENT
Bjoern A. Zeeb wrote: If that's your thread, it is. Updating to latest HEAD should have the fix. It would be great if you could confirm that everything is working again with just a plain HEAD. I can confirm that with latest HEAD it's back to normal for me with my wpi+wlan. Thanks! Doug -- This .signature sanitized for your protection ___ 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: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Lev Serebryakov wrote: Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named Doug -- This .signature sanitized for your protection ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-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: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Lev Serebryakov wrote: Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named Doug -- This .signature sanitized for your protection ___ 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: HEADSUP: arp-v2 has been committed
Li, Qing wrote: I don't think we can provide binary compatibility without putting back RTF_LLINFO exactly as it was. My preference is to continue down the new path without RTF_LLINFO. Out of curiosity, what's your reasoning for this decision? If I've missed this explanation previously, my apologies. Doug -- This .signature sanitized for your protection ___ 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: rc.firewall quick change
Julian Elischer wrote: I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule it works + fast/efficient is MUCH more important for default settings than it works really well or it works + more features. For better or worse we live in a world where most users don't read the manuals, and that includes the ones running benchmarks with default settings. OTOH I do think it would be entirely appropriate to include a better example commented out next to the fast default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel without INET
Not that I object to this at all, but out of curiosity what is the motivation? I would imagine embedded devices that run stuff not connected to the 'net but hoping for something more interesting/exciting. :) Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Named Listen IP
Onur Aslan wrote: Hi. I am using named for a ns server. Named listening all ips for my machine. But when i reboot machine, my ppp network connecting after started named. Do you mean that the ppp startup script starts running before the named startup script starts running, but doesn't finish connecting until named starts? If so, then the solution that Ian gave you (to add '/etc/rc.d/named restart' to your ppp script) is the right one. Or do you mean that the named startup script runs first, then the ppp startup script runs after it? This shouldn't happen, but if it's happening to you we need to know why. Follow these steps: mkdir testrc cd testrc cp /etc/rc . fetch http://dougbarton.us/rc-debug.diff patch rc-debug.diff /bin/sh rc If the two early runs are different it will show that, in which case there is an even bigger problem. What usually happens is that they are the same and the second one will be deleted. Paste the results of rc.early1 (and 2 if they are different) and rc.late into your response and we'll take it from there. hope this helps, Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: permissions on /etc/namedb
Eugene Grosbein wrote: On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: I need /etc/namedb to be owned by root:bind and have permissions 01775, so bind may write to it but may not overwrite files that belong to root here, and I made it so. I understand your frustration with something having changed that you did not expect. I would like to ask you though, what are you trying to accomplish here? What you suggested isn't really good from a security perspective because if an attacker does get in they can remove files from the directory that are owned by root and replace them with their own versions. Can he? Doesn't sticky bit on the directory prevent him from that? That's a question that you can and should answer for yourself. That was rhetorical quostion - I wished to give you a chance to correct yourself :-) Cheer :-) mkdir teststicky chmod 1755 teststicky/ cd teststicky/ sudo touch foofile ls -la . total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile rm foofile override rw-r--r-- root/wheel for foofile? y ls -la total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ You might also want to read sticky(8), especially the bit where it says, A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is ... the owner of the directory ... If you give me a better idea what you're trying to do then I can give you some suggestions on how to make it happen. Well, I just want bind be allowed to write to is working directory. I think that your idea of BIND's working directory is probably flawed That's not my idea. From /var/log/messages: Aug 3 15:02:18 host named[657]: the working directory is not writable That is a quaint reminder of a simpler time. It's far better nowadays to separate the idea of configuration directories and directories that named should write to. (One could easily make the argument that this division should have been enforced from the start, and personally I never liked having named dropping stuff all over my config directory, but I digress.) but if what you want is to make /etc/namedb writable by the bind user and have it persist from boot to boot someone else already told you how to do that, so good luck. Sigh... I have to study mtree now. If it takes you more than 5 minutes, give up. :) And for what reason? Just because the system thinks it knows better what user needs. You previously agreed with me that the defaults should be appropriate for non-expert users, and I would still argue that they are. Also, I'm not sure whether you've actually looked at the default named.conf or not, but the two most common files that someone would want to write are the dump and statistics files, and there are already suitable paths for those files provided, and the bind user can actually write to them by default. It would be trivial to expand those examples to other things that are of particular interest to you. Meanwhile, it's obvious to me that you are determined to go a certain direction with this, so once again I wish you luck. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: permissions on /etc/namedb
Randy Bush wrote: my fix to all this has been /usr/ports/dns/unbound (cache only) or /usr/ports/dns/nsd (auth only) and the developers/porters are constructive and friendly Oddly enough I think of myself as constructive and friendly. :) However I can't make a default configuration that fits everyone's needs. I can only do what I can to make it safe by default. Of course the two alternatives you listed are good ones, and I encourage my clients to investigate them for their environments even if they continue using BIND since IMO diversity is a good thing, helps improve resilience, etc. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: permissions on /etc/namedb
Eugene Grosbein wrote: On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: I need /etc/namedb to be owned by root:bind and have permissions 01775, Fair enough, I misread that bit. Sorry for the confusion. I will (once again) return to my point that while I do not think what you are proposing is an appropriate default, you have the tools to do what you want to do, so good luck with it. -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: permissions on /etc/namedb
Adrian Penisoara wrote:
Hi,
On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
With the notable exception of making standard functions rndc trace and
querylog work, writing to the default file named.run, which named wants
to write in 'the working directory'. You'll have seen my solution to
that, touching named.run in case it doesn't exist then chown'ing it to
bind:wheel in /etc/rc.d/named, which I don't think endangers security.
I think that is a reasonable solution for your situation, although I
don't think it's appropriate to enable that by default. The default
configuration is supposed to be a simple local resolver setup. Users
who need more advanced features should be reading the docs.
I've not been able to find another solution, and there's no equivalent
of dump-file and statistics-file for the trace/querylog file (that I
Query logging has its own log category, so you would do something like
this:
logging {
channel queries_log {
file /var/log/queries.log;
severity debug; print-time yes;
};
category queries{ queries_log; };
};
The problem is that if you put that in your named.conf file it will
log all queries when you start named. If there is interest I can add
that to the default named.conf and add a knob to rc.conf to turn query
logging on and off by default, but I'm hesitant to add that much
complexity to something that is supposed to be simple but is already
too complex. OTOH, one could argue that even for a local resolver
there would be a non-trivial number of users who would want to enable
logging of queries ...
As for the equivalent functionality for the debug aspect of named.run,
you're right, there is no equivalent. (FYI, the fact that queries are
recorded in named.run when you bump the debug level is a side effect
of the fact that queries are logged to the resolver category at debug
level 1.) The problem is that the default_debug channel has a special
property (only receives input when debug level is 0) that cannot be
reproduced with configuration options, and you cannot redefine the
default logging channels. (but see below)
Quoting from a default distributed /etc/namedb/named.conf:
options {
// Relative to the chroot directory, if any
directory /etc/namedb;
pid-file/var/run/named/pid;
dump-file /var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
You have to take into account that directory is used for any
non-absolute pathname specified in named.conf, including the file
clauses for master/slave zones. If you were to change it now then you
would break a lot of setups.
Agreed.
I believe that the working directory and root config directory
concepts should have been dissociated.
Also agreed. :) I plan to send some feature requests to the
bind-users list based on the discussions in this thread. If you're
interested in this topic I'd suggest that you follow the discussion on
that list.
I have an (unreviewed) patch to add a debug-only option at
http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to
experiment with this. Using that patch I was able to do this:
logging {
channel our_debug {
file /var/log/named.run;
severity dynamic;
print-time yes;
debug-only yes;
};
category default { default_syslog; our_debug; };
category unmatched { null; };
};
Which duplicates the default logging configuration except that you can
now specify the location for the named.run file (or give it another
file name, etc.).
Another idea would be to add a final options { directory
/var/run/named; }; statement at the end of the file -- from the BIND
sources it appears that there is a callback function which may pickup
this final statement in order to make it the current working directory
for the named process.
The problem is that when you do a reconfig or a reload named won't be
able to see its configuration file.
Oh, and in the idea that we should keep the default configuration as
simple as possible for the average user and for whatever scenario, here
is my proposal:
dump-file /var/run/named/named_dump.db;
statistics-file /var/run/named/named.stats;
This idea is not without merit, but I actually have them separated for
a reason. The reason is sort of an intermediate level thing, but if
you want to dump the db or the stats more than once and keep more than
one version around it's more convenient to do this in a separate
directory. Also the assumption is that /var/run is supposed to be
cleaned out at each boot, and I wouldn't want to lose those files.
I'm not sure what happens when the user toggles tracing / query
logging (with rndc) -- where would these files go by default ?
That depends on how
