Re: NetBSD-current amd64 with dhcpcd connects only partially

On 13/06/2017 11:22, Robert Elz wrote: > Look for /libexec/dhcpcd-run-hooks (which should be executable) and > /libexec/dhcpcd-hooks/* which should have a bunch of files that should > be readable (do not need 'x' not that it would hurt.) I'm not sure > just where the ifconfig's get done though.

Re: NetBSD-current amd64 with dhcpcd connects only partially

Hi Thomas On 13/06/2017 08:33, Thomas Mueller wrote: > I tried again with dhcpcd and did worse, then did directly (after ps -aux and > killing job number for dhcpcd) > > ifconfig re0 inet 192.168.0.4 netmask 255.255.255.0 > route add default 192.168.0.1 > > and then was successful with "host

Re: NetBSD-current amd64 with dhcpcd connects only partially

On 13/06/2017 01:34, Thomas Mueller wrote: On my latest NetBSD-current amd64 installation, from the small hours June 11, I get mixed results with re(4) driver and wonder if there is any dhcpcd tweak that will help. On motherboard MSI Z68MA-ED55(B3), Realtek 8111E/8168 Ethernet chip, "dhcpcd

Re: upgrade to 8.99.1 - dhcpcd woe

On 07/06/2017 20:54, Iain Hibbert wrote: > in the meantime, I notice in the dhcpcd(8) manpage: > >More scripts are supplied in @DATADIR@/dhcpcd/hooks and need to be copied >to /libexec/dhcpcd-hooks if you intend to use them. > > shouldn't @DATADIR@ be converted to eg /usr/share/examples

Re: dhcpcd.conf, ntp_servers, and RCS ID?

On 02/06/17 17:31, John D. Baker wrote: The recent import of newer versions of the dhcpcd software has changed some behaviors. In the past, the default "dhcpcd.conf" included "option ntp_servers". The current default has this commented out. Some people commented that dhcpcd.conf shouldn't do

Re: wm DAD duplicate address

On 24/02/2017 10:41, Patrick Welche wrote: > On Fri, Feb 24, 2017 at 09:40:27AM +0000, Roy Marples wrote: >> On 21/02/2017 12:32, Patrick Welche wrote: >>> On Tue, Feb 21, 2017 at 12:25:00PM +, Patrick Welche wrote: >>>> wm2: DAD defended address 0.0.0.0 from 0

Re: wm DAD duplicate address

On 21/02/2017 12:32, Patrick Welche wrote: > On Tue, Feb 21, 2017 at 12:25:00PM +, Patrick Welche wrote: >> wm2: DAD defended address 0.0.0.0 from 00:15:17:1a:48:1d >> wm2: DAD defence failed for 0.0.0.0 from 00:15:17:1a:48:1d >> wm2: DAD duplicate address 0.0.0.0 from 00:15:17:1a:48:1d > ...

Re: wm DAD duplicate address

On 21/02/2017 12:32, Patrick Welche wrote: > On Tue, Feb 21, 2017 at 12:25:00PM +, Patrick Welche wrote: >> wm2: DAD defended address 0.0.0.0 from 00:15:17:1a:48:1d >> wm2: DAD defence failed for 0.0.0.0 from 00:15:17:1a:48:1d >> wm2: DAD duplicate address 0.0.0.0 from 00:15:17:1a:48:1d > ...

Re: wm DAD duplicate address

On 21/02/2017 13:25, Joerg Sonnenberger wrote: > On Tue, Feb 21, 2017 at 12:25:00PM +, Patrick Welche wrote: >> wm1: flags=0x8843 mtu 1500 >> capabilities=7ff80 >>

Re: gdb.old is broken

On 13/10/2016 10:07, Johnny Billquist wrote: > CVS do not explicitly manage directories. It's not a bug, but the way > CVS works. If you do an update, you need to give -d for CVS to create > new directories needed. But I would assume everyone here knows this. Assumption is the mother of all

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

On 20/09/2016 12:58, Rin Okuyama wrote: > On 2016/09/17 21:09, Roy Marples wrote: >> When I first proposed it offlist, we thought the current >> implementation was the correct thing. >> Here is a patch to just do as you suggest. >> http://www.netbsd.org/~roy/ip_outpu

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

On 2016-09-17 03:31, Robert Elz wrote: Date:Fri, 16 Sep 2016 23:37:40 +0100 From:Roy Marples <r...@marples.name> Message-ID: <03a78e8605c842d9d032ee3ed3a59...@mail.marples.name> | > The IN_IFF_TENTATIVE handling just breaks lots of old code. | |

Re: NFS boot fails with ip_output.c rev 1.261

On 2016-09-16 23:10, mlel...@serpens.de wrote: r...@marples.name (Roy Marples) writes: Sounds like NFS boot needs to wait for IN_IFF_TENTATIVE to clear from the address. The IN_IFF_TENTATIVE handling just breaks lots of old code. You can disable it by setting the appropriate sysctl to zero

Re: NFS boot fails with ip_output.c rev 1.261

On 16/09/2016 13:43, Rin Okuyama wrote: > NFS boot fails with ip_output.c rev 1.261 with my ERLITE (evbmips64-eb): > > root on cnmac0 > nfs_boot: trying BOOTP > cnmac0: link state DOWN (was UNKNOWN) > cnmac0: link state UP (was DOWN) > nfs_boot: BOOTP next-server: 192.168.10.128 >

Re: wapbl panic on new system with too much memory!

On 2016-09-07 22:04, Paul Goyette wrote: Are you able to test the possible fix that was proposed? Not until Friday at the earliest as I'm away on business now. Roy

Re: wapbl panic on new system with too much memory!

On 07/09/2016 09:48, Roy Marples wrote: > On 06/09/2016 08:39, Paul Goyette wrote: >> I'm in the process of installing a new machine, and I'm getting a >> reproducible panic at boot time. >> >> The machine is a Intel Core i7-6900 (8 cores, 16 threads, 3.2GHz) on a

Re: mDNSResponder name resolution broken in 7.99.4

On 06/09/2016 17:14, Richard PALO wrote: > I came across this same issue... NetBSD 7.99.36 i386 > > I tried: >> # /usr/sbin/mdnsd -debug >> CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for >> NAT-PMP announcements I see this as well on i386 but not on amd64. I suggest

Re: wapbl panic on new system with too much memory!

On 06/09/2016 08:39, Paul Goyette wrote: > I'm in the process of installing a new machine, and I'm getting a > reproducible panic at boot time. > > The machine is a Intel Core i7-6900 (8 cores, 16 threads, 3.2GHz) on an > ASUS X99-E motherboard. It is fully-populated with 8 x 16GB DDR4 DIMMs >

Re: bind -> unbound/nsd

On 2016-08-21 15:38, chris...@zoulas.com wrote: On Aug 21, 10:28am, t...@panix.com (Thor Lancelot Simon) wrote: -- Subject: Re: bind -> unbound/nsd | I am strongly opposed to removing basic server functionality present | in BSD Unix for over 30 years -- and still in widespread use -- from

Re: bind -> unbound/nsd

On 19/08/2016 07:16, Christos Zoulas wrote: > - Needs additional components nsd, openDNSSEC, ldns to match bind's > functionality Maybe we should take a step back and consider what functionality we need rather than trying to match bind. For example, I would use nsd on exactly one machine in my

Re: 800+ tests failing

On 09/08/2016 08:13, Andreas Gustafsson wrote: > Now that -current builds again, there are more than 800 failing test cases. > The ones I looked at were all failing with: > > panic: in_control > rump kernel halting... I'm seeing this as well which is causing me grief trying to work out why

Re: strange messages from -current 'dhcpcd'

Hi On 24/06/2016 23:18, John D. Baker wrote: > I've just noticed some strange log messages emitted by 'dhcpcd' on > -current (7.99.32). I've seen these on i386, amd64, and evbarm-earmv7hf. > > They are of the form: > > Jun 18 12:56:53 hostname dhcpcd[PID]: wm0: invalid UDP packet from >

Re: strange messages from -current 'dhcpcd'

On Saturday 25 June 2016 07:41:19 Paul Goyette wrote: > On Fri, 24 Jun 2016, Michael van Elst wrote: > > jdba...@mylinuxisp.com ("John D. Baker") writes: > >> Jun 18 12:56:53 hostname dhcpcd[PID]: wm0: invalid UDP packet from > >> 19.100.192.168 Jun 18 12:56:53 hostname dhcpcd[PID]: wm0: invalid

Re: gcc 5.4 and dhcpcd

On Tuesday 07 June 2016 15:28:26 Patrick Welche wrote: > You probably already saw this... On -current/amd64: > > /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c: In function > 'dhcp_set_leasefile ': > /usr/src/external/bsd/dhcpcd/dist/dhcp-common.c:833:1: error: stack > protector no t protecting

Re: Lenovo T500 hang

On 2016-06-01 10:54, Stephen Borrill wrote: Somewhere after 7.0_RC2, a problem started where the machine hangs right at the end of the kernel boot just before it prints the boot device: pad0: outputs: 44100Hz, 16-bit, stereo audio1 at pad0: half duplex, playback, capture *** HANGS HERE *** boot

Re: iwn and dhcpcd

On 16/05/2016 15:28, Patrick Welche wrote: > I have very recently started seeing on my -current/amd64 laptop: > > iwn0: soliciting a DHCP lease > iwn0: truncated packet (290) from 192.168.1.62 > iwn0: truncated packet (290) from 192.168.1.62 > ... > > and dhcpcd gives up. I am very puzzled

Re: root on sd0a on odroid-c1

On 22/02/2016 17:46, Andrew Cagney wrote: >> The USB disk is probably starting too slowly to be recognized at this >> point. There needs to be some kind of spin-up delay in the kernel to >> handle this situation. > > Ah. > > Is there any existing kernel event that would indicate a disk device >

Re: Revert CTF/DTRACE?

On 2016-02-10 22:35, chris...@zoulas.com wrote: On Feb 11, 6:25am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: Revert CTF/DTRACE? (was: Re: Automated report: NetBSD-curren | Obviously, this should have been cc'd to and | not to :) | | On Thu, 11 Feb 2016, Paul Goyette wrote:

Re: HEADS UP: new %m check for printf-alike functions

On 23/10/2015 09:09, Thomas Klausner wrote: > There is a format string modifier "%m" (printing strerror(errno)) > that's supported by syslog(), and some versions of *printf(), e.g. in > glibc. > > Compiling on -current now warns when it finds this modifier in string > passed to a function that's

Re: dhcpcd doesn't remove alias address on interface-down?

Hi Paul On 2015-07-31 03:02, Paul Goyette wrote: On Fri, 31 Jul 2015, Roy Marples wrote: This is not normal or expected! I'm very bogged down in my personal life atm, but it would help if you could capture a tcpdump of the bootp messages on the client whilst rebooting the router. dhcpcd

Re: dhcpcd doesn't remove alias address on interface-down?

Hi Paul On 2015-07-31 00:43, Paul Goyette wrote: (Running amd64 7.99.19 with kernel and userland from sources that were updated on 2015-06-26 at 00:40:42 UTC) I have a fairly simple network environment, with a single internet connection via a ISP-supplied WiFi/NAT router. I have _nothing_ in

Re: dynamically created /dev/null is a regular file

On Wednesday 24 Jun 2015 16:43:17 Brook Milligan wrote: I have been installing some -current systems (cvs from 201505311600Z to be exact) that dynamically construct /dev when booting. This seems to be the default behavior of rc when /dev is effectively empty. The problem is that /dev/null

Re: rtadvd

On 2015-06-24 23:40, Robert Swindells wrote: Is rtadvd(8) working for other people ? It was working fine for me before the change on 20150605, I don't get any errors but clients don't get any replies to requests. This was fixed in rtadvd.c r1.50 Roy

Re: default ipv6 route?

On 27/04/2015 12:16, Ted Lemon wrote: On Apr 24, 2015, at 9:55 AM, Christos Zoulas chris...@astron.com wrote: One of my ISProviders is TWC. If you don't use DHCPv6, what you end up is the link-local address for each interface (which you get anyway), and a default route to the link-local

Re: default ipv6 route?

Hi Brett On 24/04/2015 04:40, Brett Lymn wrote: I am clearly doing something wrong here. I have a machine with a wired ethernet connection that I have manually configured the ipv4 address for, it appears to have an ipv6 address: wm0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu

Re: point2point network interfaces cannot receive ipv6 packets

On 12/04/2015 17:12, Roy Marples wrote: We shouldn't really need the LLINFO flag on P2P interfaces. Here is a patch which introduces p2p_rtrequest() which installs a correct and working local route for P2P interfaces, based on an older patch for OpenBSD. I intend to commit this to fix

Re: point2point network interfaces cannot receive ipv6 packets

On Fri, 2015-04-10 at 17:27 +0100, Robert Swindells wrote: Kengo NAKAHARA k-nakah...@iij.ad.jp wrote: On 2015/04/03 16:14, Takahiro HAYASHI wrote: It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot receive ipv6 packets. This occurs on NetBSD/amd64 -current since Feb 27 2015.

Re: point2point network interfaces cannot receive ipv6 packets

Hi Sorry for the late response, been busy on the Spanish beaches! On Fri, 2015-04-10 at 17:27 +0100, Robert Swindells wrote: Kengo NAKAHARA k-nakah...@iij.ad.jp wrote: On 2015/04/03 16:14, Takahiro HAYASHI wrote: It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot receive

Re: Is there some work on a official/preinstalled Desktop for NetBSD?

On 2014-12-23 11:51, Jose Luis Rodriguez Garcia wrote: Jeremy C. Reed began a desktop based on lubuntu/lxde ; http://mail-index.netbsd.org/netbsd-desktop/2012/06/02/msg000154.html, but I haven't seen any mail about progress of this. Is someone working on this or other desktop? I use parts of

Re: Is there some work on a official/preinstalled Desktop for NetBSD?

On 2014-12-23 19:21, Alan Barrett wrote: On Tue, 23 Dec 2014, Jeremy C. Reed wrote: I stopped work on this as I hit various issues that I didn't completely solve yet and still had more to do http://wiki.netbsd.org/light-desktop/light-desktop-todo/ Most importantly, I didn't receive much

Re: dhcpcd ignores netmask from server, installs /8 or /24 instead

On 2014-12-13 13:37, Roy Marples wrote: On 13/12/2014 04:37, John D. Baker wrote: On Fri, 12 Dec 2014, John D. Baker wrote: Following an update and a reboot, 'dhcpcd' ignores the /20 netmask presented by the ISP's DHCP server and instead installs the address with a /8 netmask instead

Re: dhcpcd ignores netmask from server, installs /8 or /24 instead

On 13/12/2014 04:37, John D. Baker wrote: On Fri, 12 Dec 2014, John D. Baker wrote: Following an update and a reboot, 'dhcpcd' ignores the /20 netmask presented by the ISP's DHCP server and instead installs the address with a /8 netmask instead (the address assigned by the DHCP server would

Re: dhcpcd ignores netmask from server, installs /8 or /24 instead

On Friday 12 Dec 2014 17:40:06 John D. Baker wrote: Clever as 'dhcpcd' may be, I gave it a shot but it's just not the right tool for this situation--netmask issues aside. netmask issues aside, why is dhcpcd not the right tool so they can be addressed please? dhclient has long be slated for

Re: recent dhcpcd looping on ppp0

On 2014-09-29 19:29, Frank Kardel wrote: Much better now. The busy wait loop is now gone. A new dhcpcd with this fix has been imported into -current. Roy

Re: recent dhcpcd looping on ppp0

Hi Frank On 2014-09-28 22:58, Frank Kardel wrote: On 09/28/14 23:17, Roy Marples wrote: On Sunday 28 Sep 2014 22:06:47 Roy Marples wrote: Going to guess that ppp0 doesn't have a carrier status OR IFF_RUNNING set? The attached patch should reduce the log spam, let me know how it works out

Re: recent dhcpcd looping on ppp0

On 2014-09-29 11:33, Roy Marples wrote: Going to guess that ppp0 doesn't have a carrier status OR IFF_RUNNING set? The attached patch should reduce the log spam, let me know how it works out. Errm, this patch should do better! Well, less spam, but still - busy wait (repeated count goes

Re: recent dhcpcd looping on ppp0

Hi Frank On Sunday 28 Sep 2014 16:14:01 Frank Kardel wrote: The recent dhcpcd version (-current around 20140927) seems to be looping on ppp* interfaces. Sep 28 15:14:11 Andromeda dhcpcd[3259]: ppp0: unknown carrier Sep 28 15:14:11 Andromeda dhcpcd[3259]: ppp0: carrier_status: Inappropriate

Re: dhcpcd, IPv6 DAD

Hi On 2014-07-29 20:16, Dave Tyson wrote: I seem to be having a bit of bother getting a T60 laptop to get an IPv6 address correctly using dhcpcd. The basic setup I have is an ADSL router hardwired to a server (current-ish NetBSD amd64) which gets an ipv6 feed via a HE tunnel. The router hands

Re: dhcpd build failure since last update

Hi Greg On 29/06/2014 2:53, Greg A. Woods wrote: I'm getting the following error with today's -current (2014-06-27T21:16:06Z). In function 'dhcpcd_startinterface': /once/rest/work/woods/m-NetBSD-current/external/bsd/dhcpcd/dist/dhcp6.h:244:33: error: statement with no effect

Re: Network attack?

On 26/02/2014 21:37, chris...@astron.com wrote: In article m2mwhem251@athene.hamartun.priv.no, Tom Ivar Helbekkmo t...@hamartun.priv.no wrote: Paul Goyette p...@whooppee.com writes: But definitely thanks for the info - if (when) it happens again, I will try disabling the transmission

Re: Help for PR kern/46606 is needed

Hi On 25/11/2013 10:33, Ryo ONODERA wrote: pulseaudio needs pkgsrc/sysutils/hal, and running hal causes PR kern/46606 kernel panic when the NetBSD system is shutdown. See http://gnats.netbsd.org/46606 (and duplicated bug http://gnats.netbsd.org/47012 ). How to debug this problem? This problem

Re: link problems

On 11/10/2013 19:40, Frank Kardel wrote: should I make the rest if the list from my build available ? I will try and fix all curses/termcap fallout for sure as regardless of any binutils fix, it is incorrect. I already have a list of over 200 packages which directly depend on ncurses for

Re: HEAD UP: dhcpcd-6.0.0 imported

On 22/06/2013 1:05, chris...@astron.com wrote: In article a9948c38b28e187bd6ad529e4ec4a...@mail.marples.name, Roy Marples r...@marples.name wrote: On 21/06/2013 22:39, John Nemeth wrote: On Jun 21, 8:55pm, Roy Marples wrote: } * a DUID is now generated in /etc/dhcpcd.duid and this is used

<    1   2