Re: named unable to bind to address?
On Mon, 17 Aug 2015, Eric Haszlakiewicz wrote: On August 17, 2015 12:17:37 PM EDT, John D. Baker jdba...@mylinuxisp.com wrote: I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? Is your address set by dhcp, or statically? If the former, then The address is statically assigned via the corresponding /etc/ifconfig.bge? files. I've noticed (on the rare occasions when I have access to the machine's console) that any change to the interfaces causes them to report no carrier for a brief period afterward, even though there's been no change to their physical connection. Perhaps this persists long enough to cause 'named' to ignore the interface? On Mon, 17 Aug 2015 11:19:54 -0700 Brian Buhrow buh...@nfbcal.org wrote: hello. what if you put a line like: !sleep 30 in your /etc/ifconfig.* files to make sure the interfaces are up before you try to bind to them? Still a hack, but not as bad as the cron job. Given my above observation, this seems an eminently reasonable thing to try. I'll do that when the machine is finished with its current task and can be rebooted. -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: agr issue in netbsd-7
On Mon, Aug 17, 2015 at 09:01:17AM +0200, Havard Eidnes wrote: On Thu, Jul 30, 2015 at 10:25:36PM +0200, Havard Eidnes wrote: I tried to configure a port channel (agr0). When I configure the port channel only with bnx0 or only with bnx1 everything works. If I use bnx0 and bnx1, the Cisco switch sets one of the two links to suspended mode. If I'm not terribly mistaken, the problem is that both physical interfaces are supposed to pick one of the ethernet addresses and use it as the source MAC for all the traffic passed on the aggregate logical interface. Apparently, the bnx driver in NetBSD doesn't (yet) have the ability to change the source MAC address. you should be able to change it manually with ifconfig (or put the appropriate commands in /etc/ifconfig.bnx*) so that both use the same address. I've done this in the past and it worked. Really? OK, I may have to test that again. But why doesn't that happen automatically? On another host I run an agr0 interface over a wm0/wm1 combination, and I don't have to tweak anything manually wrt. MAC addresses to make that work. because there's 2 different interfaces to change the active MAC address: SIOCINITIFADDR (with AF_LINK) and SIOCALIFADDR. agr uses the former, but it's not supported by all interfaces. ifconfig uses the later. agr should probably be fixed to use the later too, but I've never had the time to look at it deeper. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: named unable to bind to address?
On Mon, 17 Aug 2015, John D. Baker wrote: On Mon, 17 Aug 2015 11:19:54 -0700 Brian Buhrow buh...@nfbcal.org wrote: hello. what if you put a line like: !sleep 30 in your /etc/ifconfig.* files to make sure the interfaces are up before you try to bind to them? Still a hack, but not as bad as the cron job. Given my above observation, this seems an eminently reasonable thing to try. I'll do that when the machine is finished with its current task and can be rebooted. This works quite well. In fact, !sleep 1 is sufficient to let 'named' successfully bind to the IP address of the bge1 interface. -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: named unable to bind to address?
On Mon, 17 Aug 2015, John D. Baker wrote: I tried putting in an @reboot cron job to wait a couple of minutes and restart 'named', but that seems to have no effect. Perhaps wait longer? Oops. I discovered an omission in my crontab entry. But that's just an attempted workaround. It works now, but I really shouldn't need it. Suggestions? -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: named unable to bind to address?
Playing with my @reboot crontab entry, since 'cron' is started last, the elapsed time since 'named' was first started is enough and no additional delay is needed. As such, it simply restarts 'named' and then external queries are received/answered. I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: named unable to bind to address?
I don't know why your bge1 isn't available yet. Maybe look in your dmesg for more details about it and share here. As another workaround, maybe use sleep with some amount of seconds in your named startup script to delay its startup to make sure your bge1 is up. (By the way, named has automatic-interface-scan and interface-interval options that may help for later interface listening (defaults yes and 60 seconds).)
Re: named unable to bind to address?
On August 17, 2015 12:17:37 PM EDT, John D. Baker jdba...@mylinuxisp.com wrote: Playing with my @reboot crontab entry, since 'cron' is started last, the elapsed time since 'named' was first started is enough and no additional delay is needed. As such, it simply restarts 'named' and then external queries are received/answered. I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? Is your address set by dhcp, or statically? If the former, then perhaps you could have the dhclient script kick named after the address is set, or more generically use ifwatchd to do the same thing. Eric
Re: obsolete gcc-4.5 include directory insufficient
On Fri, 14 Aug 2015, John D. Baker wrote: Running 'postinstall fix obsolete' on amd64 fails due to the following file remaining in /usr/include/gcc-4.5: $ ls -laF /usr/include/gcc-4.5 total 24 drwxr-xr-x 2 root wheel 1024 Aug 14 10:43 ./ drwxr-xr-x 61 root wheel 5120 Aug 13 10:00 ../ -r--r--r-- 1 root wheel 3811 Sep 23 2011 omp.h The same leftover file is present on i386 as well. -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: named unable to bind to address?
John D. Baker wrote: Playing with my @reboot crontab entry, since 'cron' is started last, the elapsed time since 'named' was first started is enough and no additional delay is needed. As such, it simply restarts 'named' and then external queries are received/answered. I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? Perhaps this is fallout from the change announced on current-users in May with the subject line HEAD UP - IPv4 addresses now have flags? http://mail-index.netbsd.org/current-users/2015/05/02/msg027329.html -- Andreas Gustafsson, g...@gson.org
daily CVS update output
Updating src tree: P src/external/gpl3/Makefile P src/external/gpl3/gdb/Makefile.inc P src/external/gpl3/gdb/bin/gdbtui/tui-main.c P src/external/gpl3/gdb/dist/config.guess P src/external/gpl3/gdb/dist/config.sub P src/external/gpl3/gdb/dist/bfd/bfdio.c P src/external/gpl3/gdb/dist/bfd/config.bfd P src/external/gpl3/gdb/dist/bfd/configure P src/external/gpl3/gdb/dist/bfd/elf.c P src/external/gpl3/gdb/dist/bfd/elf32-i386.c P src/external/gpl3/gdb/dist/bfd/netbsd-core.c P src/external/gpl3/gdb/dist/bfd/doc/Makefile.am P src/external/gpl3/gdb/dist/bfd/doc/Makefile.in P src/external/gpl3/gdb/dist/bfd/doc/bfd.info P src/external/gpl3/gdb/dist/gdb/alphabsd-nat.c P src/external/gpl3/gdb/dist/gdb/alphanbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/amd64bsd-nat.c P src/external/gpl3/gdb/dist/gdb/amd64nbsd-nat.c P src/external/gpl3/gdb/dist/gdb/amd64nbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/arm-tdep.c P src/external/gpl3/gdb/dist/gdb/armnbsd-nat.c P src/external/gpl3/gdb/dist/gdb/armnbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/bsd-kvm.c P src/external/gpl3/gdb/dist/gdb/configure P src/external/gpl3/gdb/dist/gdb/configure.ac P src/external/gpl3/gdb/dist/gdb/configure.host P src/external/gpl3/gdb/dist/gdb/configure.tgt P src/external/gpl3/gdb/dist/gdb/d-exp.c P src/external/gpl3/gdb/dist/gdb/hppa-tdep.c P src/external/gpl3/gdb/dist/gdb/hppa-tdep.h P src/external/gpl3/gdb/dist/gdb/hppanbsd-nat.c P src/external/gpl3/gdb/dist/gdb/hppanbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/i386bsd-nat.c P src/external/gpl3/gdb/dist/gdb/i386bsd-nat.h P src/external/gpl3/gdb/dist/gdb/i386nbsd-nat.c P src/external/gpl3/gdb/dist/gdb/i386nbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/inf-ptrace.c P src/external/gpl3/gdb/dist/gdb/m68kbsd-nat.c P src/external/gpl3/gdb/dist/gdb/m68kbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/mips-tdep.h P src/external/gpl3/gdb/dist/gdb/mipsnbsd-nat.c P src/external/gpl3/gdb/dist/gdb/mipsnbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/nbsd-thread.c P src/external/gpl3/gdb/dist/gdb/objfiles.c P src/external/gpl3/gdb/dist/gdb/p-exp.y P src/external/gpl3/gdb/dist/gdb/ppcnbsd-nat.c P src/external/gpl3/gdb/dist/gdb/regcache.c P src/external/gpl3/gdb/dist/gdb/remote.c P src/external/gpl3/gdb/dist/gdb/sh-tdep.c P src/external/gpl3/gdb/dist/gdb/shnbsd-nat.c P src/external/gpl3/gdb/dist/gdb/shnbsd-tdep.c P src/external/gpl3/gdb/dist/gdb/solib.c P src/external/gpl3/gdb/dist/gdb/sparc-nat.c P src/external/gpl3/gdb/dist/gdb/sparc64nbsd-nat.c P src/external/gpl3/gdb/dist/gdb/sparcnbsd-nat.c P src/external/gpl3/gdb/dist/gdb/ui-file.c P src/external/gpl3/gdb/dist/gdb/user-regs.c P src/external/gpl3/gdb/dist/gdb/utils.c P src/external/gpl3/gdb/dist/gdb/varobj.c P src/external/gpl3/gdb/dist/gdb/vaxbsd-nat.c P src/external/gpl3/gdb/dist/gdb/common/agent.c P src/external/gpl3/gdb/dist/gdb/common/common-defs.h P src/external/gpl3/gdb/dist/gdb/tui/tui-stack.c P src/external/gpl3/gdb/dist/libiberty/make-temp-file.c P src/external/gpl3/gdb/dist/libiberty/strerror.c P src/external/gpl3/gdb/dist/opcodes/cgen.sh P src/external/gpl3/gdb/dist/opcodes/configure P src/external/gpl3/gdb/dist/sim/configure P src/external/gpl3/gdb/dist/sim/common/callback.c P src/external/gpl3/gdb/dist/sim/mn10300/Makefile.in P src/external/gpl3/gdb/dist/sim/ppc/hw_memory.c P src/external/gpl3/gdb/dist/sim/v850/Makefile.in P src/external/gpl3/gdb/lib/libbfd/Makefile P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd-in3.h P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd.h P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfd_stdint.h P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/bfdver.h P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/config.h P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/defs.mk P src/external/gpl3/gdb/lib/libbfd/arch/x86_64/targmatch.h P src/external/gpl3/gdb/lib/libdecnumber/arch/x86_64/gstdint.h P src/external/gpl3/gdb/lib/libgdb/Makefile P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/config.h P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/defs.mk P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/init.c P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/jit-reader.h P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/observer.h P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/observer.inc P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/version.c P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/xml-builtin.c P src/external/gpl3/gdb/lib/libgdb/arch/x86_64/build-gnulib/config.h P src/external/gpl3/gdb/lib/libiberty/arch/x86_64/config.h P src/external/gpl3/gdb/lib/libiberty/arch/x86_64/defs.mk P src/external/gpl3/gdb/lib/libopcodes/arch/x86_64/config.h P src/external/mit/xorg/server/drivers/xf86-video-sunffb/Makefile P src/lib/librumpuser/rumpuser.c P src/lib/librumpuser/rumpuser_port.h P src/lib/librumpuser/rumpuser_sp.c P src/share/mk/bsd.own.mk P src/sys/arch/sparc/stand/bootblk/bootblk.fth P src/sys/arch/sparc/stand/bootblk/genlfs.cf P src/sys/arch/xen/xen/xbd_xenbus.c P src/sys/dev/cgd.c P src/sys/dev/dksubr.c P src/sys/dev/dkvar.h P src/sys/dev/ld.c P
Re: named unable to bind to address?
hello. what if you put a line like: !sleep 30 in your /etc/ifconfig.* files to make sure the interfaces are up before you try to bind to them? Still a hack, but not as bad as the cron job. -Brian On Aug 17, 10:35am, John D. Baker wrote: } Subject: Re: named unable to bind to address? } On Mon, 17 Aug 2015, John D. Baker wrote: } } I tried putting in an @reboot cron job to wait a couple of minutes and } restart 'named', but that seems to have no effect. Perhaps wait longer? } } Oops. I discovered an omission in my crontab entry. } } But that's just an attempted workaround. } } It works now, but I really shouldn't need it. } } Suggestions? } } -- } |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X } |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD } | X No HTML/proprietary data in email. BSD just sits there and works! } |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645 } -- End of excerpt from John D. Baker
Re: named unable to bind to address?
On Mon, 17 Aug 2015, John D. Baker wrote: additional delay is needed. As such, it simply restarts 'named' and then external queries are received/answered. I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? On Mon, 17 Aug 2015 19:47:36 +0300, Andreas Gustafsson g...@gson.org wrote: John D. Baker wrote: I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? Perhaps this is fallout from the change announced on current-users in May with the subject line HEAD UP - IPv4 addresses now have flags? http://mail-index.netbsd.org/current-users/2015/05/02/msg027329.html That seems to be the case. But On Mon, 17 Aug 2015 11:54:41 -0500 (CDT), Jeremy C. Reed r...@reedmedia.net wrote: I don't know why your bge1 isn't available yet. Maybe look in your dmesg for more details about it and share here. Looks fairly ordinary to me (both interfaces shown since I've run with each of them with the same result): [...] bge0 at pci1 dev 6 function 0: Broadcom BCM5703X Gigabit Ethernet bge0: interrupting at ioapic1 pin 12 bge0: HW config 0115, , , bge0: ASIC BCM5702/5703 A2 (0x1002), Ethernet address xx:xx:xx:xx:xx:xx brgphy0 at bge0 phy 1: BCM5703 1000BASE-T media interface, rev. 2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1 at pci1 dev 8 function 0: Broadcom BCM5703X Gigabit Ethernet bge1: interrupting at ioapic1 pin 13 bge1: HW config 0115, , , bge1: ASIC BCM5702/5703 A2 (0x1002), Ethernet address xx:xx:xx:xx:xx:xx brgphy1 at bge1 phy 1: BCM5703 1000BASE-T media interface, rev. 2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto [...] The only slightly odd thing I noticed was that the device was being marked up before the IPv4 address was assigned. Changing it so address assignment came first and then marking it up made no difference. (By the way, named has automatic-interface-scan and interface-interval options that may help for later interface listening (defaults yes and 60 seconds).) I noticed that in the full sequence of messages, 'named' tries twice to bind to the external address--once at the beginning and once again near the end of its startup procedure. It fails both times. I see no evidence in the log files that it ever tries again afterward, though. -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645 From g...@gson.org Mon Aug 17 11:57:27 2015 Date: Mon, 17 Aug 2015 19:47:36 +0300 From: Andreas Gustafsson g...@gson.org To: John D. Baker jdba...@mylinuxisp.com Cc: current-users@NetBSD.org Subject: Re: named unable to bind to address? John D. Baker wrote: Playing with my @reboot crontab entry, since 'cron' is started last, the elapsed time since 'named' was first started is enough and no additional delay is needed. As such, it simply restarts 'named' and then external queries are received/answered. I still shouldn't need this. Why is the address not available when the first attempt to start 'named' is made? Perhaps this is fallout from the change announced on current-users in May with the subject line HEAD UP - IPv4 addresses now have flags? http://mail-index.netbsd.org/current-users/2015/05/02/msg027329.html -- Andreas Gustafsson, g...@gson.org From r...@reedmedia.net Mon Aug 17 11:57:29 2015 Date: Mon, 17 Aug 2015 11:54:41 -0500 (CDT) From: Jeremy C. Reed r...@reedmedia.net To: John D. Baker jdba...@mylinuxisp.com Cc: current-users@NetBSD.org Subject: Re: named unable to bind to address? As another workaround, maybe use sleep with some amount of seconds in your named startup script to delay its startup to make sure your bge1 is up. (By the way, named has automatic-interface-scan and interface-interval options that may help for later interface listening (defaults yes and 60 seconds).)
named unable to bind to address?
I've been working on a machine that's been running -current for a while now. It seems that after the latest BIND updates, 'named' has trouble binding to an external IP address at which to listen for queries when starting up after a reboot. $ uname -a NetBSD brenowin.reltuk.net 7.99.21 NetBSD 7.99.21 (BRENOWIN) #5: Mon Aug 17 09:35:54 CDT 2015 sy...@brenowin.reltuk.net:/d0/build/current/obj/i386/sys/arch/i386/compile/BRENOWIN i386 The following is relevant excerpt from /var/log/messages: [...] Aug 17 10:04:34 brenowin named[611]: found 4 CPUs, using 4 worker threads Aug 17 10:04:34 brenowin named[611]: using 2 UDP listeners per interface Aug 17 10:04:34 brenowin named[611]: using up to 4096 sockets Aug 17 10:04:34 brenowin named[611]: loading configuration from '/etc/named.conf' Aug 17 10:04:34 brenowin named[611]: reading built-in trusted keys from file 'bind.keys' Aug 17 10:04:34 brenowin named[611]: max open files (3404) is smaller than max sockets (4096) Aug 17 10:04:34 brenowin named[611]: using default UDP/IPv4 port range: [49152, 65535] Aug 17 10:04:34 brenowin named[611]: listening on IPv4 interface bge1, x.y.z.q#53 Aug 17 10:04:34 brenowin named[611]: could not listen on UDP socket: address not available Aug 17 10:04:34 brenowin named[611]: creating IPv4 interface bge1 failed; interface ignored Aug 17 10:04:34 brenowin named[611]: listening on IPv4 interface lo0, 127.0.0.1#53 Aug 17 10:04:34 brenowin named[611]: generating session key for dynamic DNS [...] In this state, 'ps' shows 'named' running, and one can watch incoming queries, but no replies are ever sent. If I log into the machine and restart 'named' manually, it starts working. I tried putting in an @reboot cron job to wait a couple of minutes and restart 'named', but that seems to have no effect. Perhaps wait longer? But that's just an attempted workaround. Suggestions? -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: --- dependall-external --- /tmp/bracket/build/2015.08.15.10.31.41-i386/src/external/gpl3/gdb/dist/bfd/archive.c: In function '_bfd_archive_close_and_cleanup': /tmp/bracket/build/2015.08.15.10.31.41-i386/src/external/gpl3/gdb/dist/bfd/archive.c:2775:11: error: 'bfd' has no member named 'is_linker_output' if (abfd-is_linker_output) ^ In case you are wondering why there were two build failure reports with the same error message, it does actually look like the i386 build was broken twice, on the 15th and the 16th, and fixed inbetween, and failed in the same place both times. The other confusing thing is that the two reports were sent to current-users out of order; perhaps the first one got moderated due to its size? In any case, the failure of the 16th is still not fixed (hi Christos!). -- Andreas Gustafsson, g...@netbsd.org
Re: agr issue in netbsd-7
On Thu, Jul 30, 2015 at 10:25:36PM +0200, Havard Eidnes wrote: I tried to configure a port channel (agr0). When I configure the port channel only with bnx0 or only with bnx1 everything works. If I use bnx0 and bnx1, the Cisco switch sets one of the two links to suspended mode. If I'm not terribly mistaken, the problem is that both physical interfaces are supposed to pick one of the ethernet addresses and use it as the source MAC for all the traffic passed on the aggregate logical interface. Apparently, the bnx driver in NetBSD doesn't (yet) have the ability to change the source MAC address. you should be able to change it manually with ifconfig (or put the appropriate commands in /etc/ifconfig.bnx*) so that both use the same address. I've done this in the past and it worked. Really? OK, I may have to test that again. But why doesn't that happen automatically? On another host I run an agr0 interface over a wm0/wm1 combination, and I don't have to tweak anything manually wrt. MAC addresses to make that work. I should perhaps mention that I've been testing agr with bnx on netbsd-6 code. Regards, - Håvard
