Re: Problems with dhcpcd

On Mon, 09 Oct 2023 12:41:30 +0100 Roy Marples wrote --- > On Mon, 09 Oct 2023 11:33:16 +0100 Roy Marples wrote --- > > On Sun, 08 Oct 2023 21:58:54 +0100 Lloyd Parkes wrote --- > > > > > > > > > On 8/10/23 15:30,

Re: Problems with dhcpcd

On Mon, 09 Oct 2023 11:33:16 +0100 Roy Marples wrote --- > On Sun, 08 Oct 2023 21:58:54 +0100 Lloyd Parkes wrote --- > > > > > > On 8/10/23 15:30, Lloyd Parkes wrote: > > I found the problem. The syslog function in /libexec/dhcpcd-run-hook

Re: Problems with dhcpcd

On Sun, 08 Oct 2023 21:58:54 +0100 Lloyd Parkes wrote --- > > > On 8/10/23 15:30, Lloyd Parkes wrote: > I found the problem. The syslog function in /libexec/dhcpcd-run-hooks > tries to echo text to stdout/stderr and the shell script gets killed > with SIGPIPE when it's being run

Re: Problems with dhcpcd

ght away so any assignments from the DHCP lease won't apply right away. Is this what you are seeing? Is the hostname even there? You can examine the contents of your leases with `dhcpcd -U`. I have only just imported dhcpcd-10.0.3 to -current. Unlikely to address this exact issue (if there is one yet), but you never know. Roy Marples

Re: zfs howto

On 14/02/2021 09:35, J. Hannken-Illjes wrote: The trigger is '-maproot' with group(s), first bug is mountd leaving 'cr_gid' as -2 and setting the first group list member to 10 in this case. Second bug is ZFS setting illegal group id -2 aka 4294967294 to GID_NOBODY with id -2. Later this

Re: zfs howto

On 12/02/2021 14:44, Greg Troxel wrote: Long ago I rototilled to zfs howto adding far more questions than answers. I just did another rototill pass. https://wiki.netbsd.org/zfs/ While many \todos remain, the biggest questions I have are about NFS: If I want to export a zfs filesystem

Re: Automated report: NetBSD-current/i386 build failure

On 03/02/2021 17:55, Ryo ONODERA wrote: Exactly. It happens in dtrace userland build. Fixed. Sorry about that. Maybe we should not define CTASSERT ourselves and just use __CTASSERT to avoid this in the future? Roy

Re: Automated report: NetBSD-current/i386 build failure

On 03/02/2021 14:42, Ryo ONODERA wrote: Hi, It seems that CTASSERT in netinet/in.h conflicts with CTASSERT in external/cddl/osnet/dist/uts/common/sys/debug.h. Ryo ONODERA writes: Hi, However I have gotten another failure: --- dt_print.pico --- In file included from

Re: Help with libcurses and lynx under NetBSD-9 and -current?

On 02/02/2021 09:44, Brett Lymn wrote: Why don't you post your $TERMCAP and infocmp output here? Umm I don't have a problem with using terminfo. I am more interested in working out why lynx is misbehaving in window. I suspect that is something I did wrong when I fixed another PR to do with

Re: Help with libcurses and lynx under NetBSD-9 and -current?

On 01/02/2021 09:53, Brett Lymn wrote: The TERMCAP variable has some severe liitations, the worst being it can only be 256bytes in size which was more than adequate for a vt100 definition but a modern colour xterm definition simply won't fit in that space, terminfo does not have these

Re: Routing socket issue?

Hi Frank :) On 31/01/2021 07:58, Frank Kardel wrote: For example I fail to see how RTM_LOSING helps that because it won't change how ntpd would configure itself. Well if I read the comment right I am inclined to differ here: In in_pcs.c we find: /*  * Check for alternatives when higher level

Re: Routing socket issue?

On 30/01/2021 18:27, Paul Goyette wrote: On Sat, 30 Jan 2021, Roy Marples wrote: On 30/01/2021 15:12, Paul Goyette wrote: I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket

Re: Routing socket issue?

On 30/01/2021 18:27, Paul Goyette wrote: On Sat, 30 Jan 2021, Roy Marples wrote: On 30/01/2021 15:12, Paul Goyette wrote: I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket

Re: Routing socket issue?

On 30/01/2021 15:12, Paul Goyette wrote: I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket reports: No buffer space available I recently adding a patch to enable the diagnostic

Re: Help with libcurses and lynx under NetBSD-9 and -current?

On 27/01/2021 17:52, Christos Zoulas wrote: In article , RVP wrote: This might be due to the fact that window(1) relies on setting a custom TERMCAP environment variable to inform programs running under it of the term. capabilities it supports, and the curses library no longer makes use of

Re: Using wg(4) with a commerical VPN provider

On 11/11/2020 01:49, Brad Spencer wrote: @@ -2352,6 +2361,7 @@ if (*af == AF_INET) { packet_len = ntohs(ip->ip_len); } else { +#ifdef INET6 const struct ip6_hdr *ip6; if (__predict_false(decrypted_len < sizeof(struct ip6_hdr))) Might be

Re: Automated report: NetBSD-current/i386 test failure (l2tp)

On 23/10/2020 08:25, Andreas Gustafsson wrote: Roy Marples wrote: This is rump crashing and I don't know why. If the rump kernel crashes in the test, that likely means the real kernel will crash in actual use. I can't get a backtrace to tell me where the problem is. I managed to get one

Re: Automated report: NetBSD-current/i386 test failure (l2tp)

Hi Andreas On 22/10/2020 09:00, Andreas Gustafsson wrote: Hi Roy, On Oct 16, the NetBSD Test Fixture wrote: The newly failing test cases are: net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv4 net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv6 net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv4

Re: Automated report: NetBSD-current/i386 test failure

On 16/10/2020 15:54, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/if_wg/t_basic:wg_basic_ipv6_over_ipv4 net/if_wg/t_basic:wg_basic_ipv6_over_ipv6

Re: Automated report: NetBSD-current/i386 test failure

On 14/10/2020 07:15, Andreas Gustafsson wrote: On Oct 8, the NetBSD Test Fixture wrote: The newly failing test cases are: net/carp/t_basic:carp_handover_ipv4_halt_carpdevip net/carp/t_basic:carp_handover_ipv4_halt_nocarpdevip net/carp/t_basic:carp_handover_ipv4_ifdown_carpdevip

Re: gdb - undefined reference to `std::__1::codecvt::id'

On 29/09/2020 20:26, Christos Zoulas wrote: Or use gcc instead of clang :-) Ew

Re: gdb - undefined reference to `std::__1::codecvt::id'

On 29/09/2020 17:13, Kamil Rytarowski wrote: The basesystem libc++ is too old for C++ applications like GDB. I find that dubious as we have the new gdb building fine on amd64 and i386 with gnu compiler according to our test runs. Unless the machine has a local override. This is clang

gdb - undefined reference to `std::__1::codecvt::id'

# link gdb/gdb /usr/tools/bin/x86_64--netbsd-clang++--sysroot=/ -Wl,--warn-shared-textrel -Wl,-z,relro -pie -o gdb gdb.o -Wl,-rpath-link,/lib -L=/lib -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdb/obj.amd64 -lgdb

Re: Automated report: NetBSD-current/i386 test failure

On 23/09/2020 11:42, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: net/if/t_ifconfig:ifconfig_options The above test failed in each of the last 4 test runs, and passed in at least 26

Re: Automated report: NetBSD-current/i386 test failure

On 20/09/2020 04:40, Robert Elz wrote: Date:Sun, 20 Sep 2020 04:02:45 +0100 From:Roy Marples Message-ID: <51d2f8dc-d059-5eae-9899-5c91539d1...@marples.name> | The test case just needed fixing. That is not uncommon after changes elsewhere. | Th

Re: Automated report: NetBSD-current/i386 test failure

On 13/09/2020 23:10, Robert Elz wrote: Date:Sun, 13 Sep 2020 22:14:00 +0100 From:Roy Marples Message-ID: | >| > net/arp/t_arp:arp_proxy_arp_pub | >| > net/arp/t_arp:arp_proxy_arp_pubproxy | > | > Those two

Re: arp: ioctl(SIOCGNBRINFO): Inappropriate ioctl for device

On 16/09/2020 10:23, Thomas Klausner wrote: On Wed, Sep 16, 2020 at 11:10:55AM +0200, Martin Husemann wrote: On Wed, Sep 16, 2020 at 11:05:49AM +0200, Thomas Klausner wrote: The one with 192.168.0.x configured is wm0. (I only have an lo0 except for that.) Strange, your kernel is newer or

Re: Automated report: NetBSD-current/i386 test failure

On 13/09/2020 22:07, Robert Elz wrote: Date:Sun, 13 Sep 2020 20:06:45 +0100 From:Roy Marples Message-ID: <9e977478-d209-2dbb-49d9-3fa9acd25...@marples.name> | > net/arp/t_arp:arp_cache_expiration_10s | > net/arp/t_arp:arp_cache_e

Re: Automated report: NetBSD-current/i386 test failure

On 12/09/2020 22:57, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/arp/t_arp:arp_cache_expiration_10s net/arp/t_arp:arp_cache_expiration_5s net/arp/t_arp:arp_command

Re: Automated report: NetBSD-current/i386 build failure

On 12/09/2020 07:40, NetBSD Test Fixture wrote: This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2020.09.12.01.36.26. An extract from the build.sh output follows:

Re: Automated report: NetBSD-current/i386 build failure

On 12/06/2020 16:13, NetBSD Test Fixture wrote: This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2020.06.12.11.21.36. An extract from the build.sh output follows:

Re: problem w/dhcpcd vs libsupc++.a on sparc?

On 21/04/2020 09:07, Roy Marples wrote: On 21/04/2020 00:02, John D. Baker wrote: On Mon, 20 Apr 2020, r...@marples.name wrote: Anyway the patch linked below should fix this. https://roy.marples.name/cgit/dhcpcd.git/patch/?id=1dc1fce7ae7b4c106a8eb631ed92ab1ed8e86bbc I'm waiting

Re: problem w/dhcpcd vs libsupc++.a on sparc?

On 21/04/2020 00:02, John D. Baker wrote: On Mon, 20 Apr 2020, r...@marples.name wrote: Anyway the patch linked below should fix this. https://roy.marples.name/cgit/dhcpcd.git/patch/?id=1dc1fce7ae7b4c106a8eb631ed92ab1ed8e86bbc I'm waiting for feedback on a few more issues, so hopefully you

Re: HEADS UP: dhcpcd gains privilege separation support

Hi Oskar On 04/04/2020 07:40, os...@fessel.org wrote: Am 02.04.2020 um 15:07 schrieb Roy Marples : could it be that this _dhcpcd has been added to master.passwd and group, so please update your local ones before upgrading. Once installed, you should stop dhcpcd running and then invoke

HEADS UP: dhcpcd gains privilege separation support

_dhcpcd has been added to master.passwd and group, so please update your local ones before upgrading. Once installed, you should stop dhcpcd running and then invoke postinstall so that the old dhcpcd files (duid, secret, leases, etc) are moved to the chroot directory. Then you can start dhcpcd

Re: Automated report: NetBSD-current/i386 test failure

On 31/03/2020 12:22, NetBSD Test Fixture wrote: The newly failing test case is: usr.bin/infocmp/t_terminfo:basic This error in infocmp is now fixed. Roy

Re: ZFS on root - almost there

On 25/02/2020 21:40, Chavdar Ivanov wrote: On Tue, 25 Feb 2020 at 20:14, Roy Marples wrote: On 22/02/2020 19:22, Roy Marples wrote: https://wiki.netbsd.org/wiki/RootOnZFS/ Updated the wiki and the ramdisk - either the bootloader needs to load the modules via boot.cfg or the modules need

Re: ZFS on root - almost there

On 22/02/2020 19:22, Roy Marples wrote: https://wiki.netbsd.org/wiki/RootOnZFS/ Updated the wiki and the ramdisk - either the bootloader needs to load the modules via boot.cfg or the modules need to be built into the kernel. There's just no easy way to load the modules from the ramdisk

Re: ZFS on root - almost there

On 23/02/2020 11:56, Chavdar Ivanov wrote: On Sun, 23 Feb 2020 at 05:17, Roy Marples wrote: On 22/02/2020 21:19, Chavdar Ivanov wrote: I just noticed - the error message from the sysctl command was that the string was too long: Sync up, build a new ramdisk and install it. Should be fixed

Re: ZFS on root - almost there

On 22/02/2020 21:19, Chavdar Ivanov wrote: I just noticed - the error message from the sysctl command was that the string was too long: Sync up, build a new ramdisk and install it. Should be fixed now. Roy

Re: ZFS on root - almost there

On 22/02/2020 19:06, Chavdar Ivanov wrote: On Sat, 22 Feb 2020 at 18:03, Chavdar Ivanov wrote: On Sat, 22 Feb 2020 at 17:03, Roy Marples wrote: On 22/02/2020 16:56, Chavdar Ivanov wrote: Surely I have missed and/or misuderstood some of the above, but I am getting: ... Starting ZFS on root

Re: ZFS on root - almost there

On 22/02/2020 11:27, Roy Marples wrote: On 14/02/2020 12:58, Roy Marples wrote: So I thought I would have a go at setting up ZFS on root. I've now comitted enough to manually build a ramdisk to set this all up. Quick instruction steps which I'll document on web page later: https

Re: ZFS on root - almost there

On 22/02/2020 16:56, Chavdar Ivanov wrote: Surely I have missed and/or misuderstood some of the above, but I am getting: ... Starting ZFS on root boot strapper Copying needed kernel modules from NAME=boot:/stand/amd64/9.99.47/modules mount: no match for 'boot': No such process

Re: ZFS on root - almost there

On 14/02/2020 12:58, Roy Marples wrote: So I thought I would have a go at setting up ZFS on root. I've now comitted enough to manually build a ramdisk to set this all up. Quick instruction steps which I'll document on web page later: Compile the ramdisk cd src/distrib/amd64/ramdisks/ramdisk

Re: ZFS on root - almost there

On 14/02/2020 12:58, Roy Marples wrote: So I thought I would have a go at setting up ZFS on root. I now have a ramdisk-zfsroot configured! With just the kernel and modules on the partition I can put this in boot.cfg menu=Load ZFS Root;load solaris;load zfs;fs /ramdisk-zfsroot.fs;boot Sadly

ZFS on root - almost there

So I thought I would have a go at setting up ZFS on root. Thanks to hannken@ it now boots :) However, it panics at shutdown (or halt). Screen capture of the panic here: http://www.netbsd.org/~roy/netbsd-zfs-panic.jpg Now, what I did during the initial setup was to adjust the mountpoint of

Re: Recent if_stat changes have broken sysutils/xosview

On 09/02/2020 01:52, Jason Thorpe wrote: On Feb 8, 2020, at 4:04 PM, Paul Goyette wrote: The package no longer builds. Fails with (among others) error: 'struct ifnet' has no member named 'if_ibytes'; did you mean 'if_index'? "struct ifnet" is private to the kernel. This application

Re: Converting termcap entries to terminfo entries

Hi Brian On 22/10/2019 23:14, Brian Buhrow wrote: hello. I'm in the process of building NetBSD-9.0 systems in an effort to consider upgrading from my fleet of NetBSD-5.2 systems to NetBSD-9. As a long time window(1) user, I have a termcap entry for the window terminal type that I use

Re: dhcpcd ignores "force_hostname=YES" on diskless clients?

On 21/09/2019 03:01, John D. Baker wrote: On Fri, 20 Sep 2019, John D. Baker wrote: (Before the recent imports of later versions of 'dhcpcd', it failed to obtain the FQDN on a sparc system and set the hostname as "localhost".) The diskless SPARC system works properly now. Will have to check

Re: build issue: _REENTRANT redefined

On 06/09/2019 11:34, Thomas Klausner wrote: I guess I have to turn off the gcc build as well, but for now I'd like to have both compilers... I've not been able to build both for many years now. As my need for building xen packages out-weighs my social want for LLVM, I currently only use gcc

Re: NetBSD on a wireless router?

On 16/08/2019 04:28, Jason Thorpe wrote: On Aug 15, 2019, at 8:15 PM, John Franklin wrote: because I usually use the Ubiquiti APs for WiFi. For WiFi performance and management on a budget, they’re hard to beat. +1. I use Ubiquiti to cover the 3 levels of my house + back yard, and it

Re: CVS commit: src/usr.sbin/postinstall

On 13/06/2019 09:00, Manuel Bouyer wrote: On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: [...] I've been using etcupdate for ages so I only ever really used postinstall to fix "obsolete" and "catpages". etcupdate -a has some kinks and may be we should concentrate on fixing

Re: ipv6 broken

On 13/05/2019 13:34, Christos Zoulas wrote: In article <332662e7-3c78-5d1b-ce05-8c86806f7...@marples.name>, Roy Marples wrote: On 13/05/2019 03:00, Christos Zoulas wrote: dhcpcd says: May 13 01:47:01 [79]: wm0: ipv6_start: Can't assign requested address dhcpcd should say dupl

Re: ipv6 broken

On 13/05/2019 03:00, Christos Zoulas wrote: dhcpcd says: May 13 01:47:01 [79]: wm0: ipv6_start: Can't assign requested address dhcpcd should say duplicated adddress based on the below, but that's just cosmetic really. Kernel says: [13.119958] wm0: link state DOWN (was UNKNOWN) [

Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU

On 10/05/2019 00:40, Greg A. Woods wrote: [Thu May 9 09:24:08 2019][ 6442662.0806318] route_enqueue: queue full, dropped message There were thousands of identical lines, all separated by a few microseconds. No doubt this spew was the real cause of the apparent interrupt storm and the

Re: Automated report: NetBSD-current/i386 build failure

I think Christos has kindly fixed this for me.Roy

Re: Automated report: NetBSD-current/i386 build failure

On 22/01/2019 20:30, Andreas Gustafsson wrote: The NetBSD Test Fixture wrote: --- dhcpcd_make --- cc1: all warnings being treated as errors *** [dhcpcd.o] Error code 1 More relevant error messages from earlier in the log: --- dhcpcd_make ---

Re: failed to create llentry

On 22/11/2018 00:36, Greg Troxel wrote: Roy Marples writes: On 21/11/2018 19:51, co...@sdf.org wrote: -B -M -c /etc/wpa_supplicant.conf -s seem like really good flags, thanks. (are they good enough to be a default? right now anyone using wifi has to have wpa_supplicant_flags set, so we can't

Re: failed to create llentry

On 21/11/2018 19:51, co...@sdf.org wrote: -B -M -c /etc/wpa_supplicant.conf -s seem like really good flags, thanks. (are they good enough to be a default? right now anyone using wifi has to have wpa_supplicant_flags set, so we can't break their usage) Yes and no. We would need to ship a

Re: failed to create llentry

On 21/11/2018 18:55, co...@sdf.org wrote: I don't like debugging problems with daemonized processes. wpa_supplicant for example prints nothing to syslog. the messages it gives to stdout are informative. wpa_supplicant(8) says -s Send log messages through syslog(3) instead of to the

Re: failed to create llentry

On 21/11/2018 17:18, co...@sdf.org wrote: I use wpa_supplicant and dhcpcd. When dhcpcd fails to configure the network I start doing it manually. I don't really pay attention to when the errors occur but I'll try to keep a closer track about when they start. dhcpcd will mysteriously fail while I

Re: Travel router part 2

On 05/09/2018 14:59, D'Arcy Cain wrote: On 2018-09-05 08:03 AM, Roy Marples wrote: and have a named configured to use the forwarders in /etc/namedb/forwarders.  Whatever the ISP dhcp gives me is stuffed into the forwarders and used as last resort.  This has been a robust solution for many open

Re: Travel router part 2

On 04/09/2018 23:21, Brett Lymn wrote: On Sun, Sep 02, 2018 at 11:55:58AM -0400, D'Arcy Cain wrote: Any thoughts on picking up the DNS servers? It's not too bad because my DHCP server can be modified as needed so it is only one location and in any case I always include Google's public

Re: if_addrflags6: Can't assign requested address

On 18/08/2018 03:43, Roy Marples wrote: On 18/08/2018 03:29, SAITOH Masanobu wrote: This patch worked. if_addrflags6's error messages disappeared. :) Before this patch, Aug 18 01:00:58 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 01:30:59 amd64-n7 dhcpcd[250]: wm1

Re: if_addrflags6: Can't assign requested address

On 18/08/2018 03:29, SAITOH Masanobu wrote: This patch worked. if_addrflags6's error messages disappeared. :) Before this patch, Aug 18 01:00:58 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 01:30:59 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18

Re: if_addrflags6: Can't assign requested address

On 17/08/2018 10:08, Roy Marples wrote: On 17/08/2018 09:04, Masanobu SAITOH wrote: wm2: carrier lost wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER wm2: deleting address fe80::1392:4012:56d8:a7a2 wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign

Re: if_addrflags6: Can't assign requested address

On 17/08/2018 09:04, Masanobu SAITOH wrote: wm2: carrier lost wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER wm2: deleting address fe80::1392:4012:56d8:a7a2 wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't

Re: Running out of buffers?

On 11/08/2018 16:41, Roy Marples wrote: On 07/08/2018 17:54, Andreas Gustafsson wrote: On April 28, Roy Marples wrote: On 27/04/2018 23:58, Robert Elz wrote: We really need to turn off the error on recv() by default - and allow it to be turned on by applications that actually want to deal

Re: Running out of buffers?

On 07/08/2018 17:54, Andreas Gustafsson wrote: On April 28, Roy Marples wrote: On 27/04/2018 23:58, Robert Elz wrote: We really need to turn off the error on recv() by default - and allow it to be turned on by applications that actually want to deal with this. Why should we special case

Re: if_addrflags6: Can't assign requested address

Hi On 08/08/2018 03:13, Masanobu SAITOH wrote:  Hi.  While testing netbsd-7, I've noticed dhcpcd put the following message: Configuring network interfaces: wm0wm0: if_addrflags6: Can't assign requested address wm0: if_addrflags6: Can't assign requested address wm0: if_addrflags6: Can't

Re: if_addrflags6: Can't assign requested address

That's a real problem I'm away from any test bed until next week so I'll try and look at it then. Can you add debug to dhcpcd and maybe a logfile directive and attach the result to a reply please? Roy On 8 August 2018 04:13:30 CEST, Masanobu SAITOH wrote: > Hi. > > While testing netbsd-7,

Re: Cross-building release on MacOSX for amd64 fails...

On 04/06/2018 17:11, K. Schreiner wrote: ...like so: `progress.ro' is up to date. compile dhcpcd/dhcp.o /u/NetBSD/src/external/bsd/dhcpcd/dist/src/dhcp.c: In function 'dhcp_arp_probed': /u/NetBSD/src/external/bsd/dhcpcd/dist/src/dhcp.c:2105:2: error: implicit declaration of function

Re: Running out of buffers?

On 01/05/2018 20:21, Roy Marples wrote: Another patch. This time to handle a reported overflow listening to ND6. This one actually works Index: sys/netinet6/in6_proto.c === RCS file: /cvsroot/src/sys/netinet6/in6_proto.c,v

Re: Running out of buffers?

On 27/04/2018 21:34, Roy Marples wrote: Hi Paul On 27/04/2018 04:09, Paul Goyette wrote: I've got lots of memory, so I don't understand what buffers are not available.  Ever since upgrading to my current system (sources dated 2018-03-20 11:25:00 UTC), I've been seeing these messages at random

Re: Running out of buffers?

On 27/04/2018 23:58, Robert Elz wrote: Date:Fri, 27 Apr 2018 21:34:49 +0100 From:Roy Marples <r...@marples.name> Message-ID: <df3a6231-f417-1d79-f135-bef0fe2f5...@marples.name> | Hopefully this fixes the issues and won't impact small memory devi

Re: Running out of buffers?

Hi Paul On 27/04/2018 04:09, Paul Goyette wrote: I've got lots of memory, so I don't understand what buffers are not available.  Ever since upgrading to my current system (sources dated 2018-03-20 11:25:00 UTC), I've been seeing these messages at random intervals: Can you test the below

Re: Running out of buffers?

On 27/04/2018 09:45, Patrick Welche wrote: The very odd situation in which I saw those buffer overflows, is simply on a home machine, so flaky home broadband, running a pkg_rolling-replace. The machine has 32G of memory, but from your message that is irrelevant. The urtwmn0 was struggling

Re: Running out of buffers?

On 27/04/2018 07:05, Robert Elz wrote: Date:Fri, 27 Apr 2018 05:18:16 +0100 From:Roy Marples <r...@marples.name> Message-ID: <58598dae-238e-44a5-e74f-bbb2fdd7b...@marples.name> | No-one has yet weighed in on how this should be resolved. Go back

Re: Running out of buffers?

On 27/04/2018 04:09, Paul Goyette wrote: I've got lots of memory, so I don't understand what buffers are not available. Ever since upgrading to my current system (sources dated 2018-03-20 11:25:00 UTC), I've been seeing these messages at random intervals: Apr 23 05:51:33 speedy ntpd[526]:

Re: -current cloner interfaces broken/gone/unusable

On 23/04/2018 23:34, Robert Swindells wrote: Frank Kardel wrote: using -current as of 20180421 (NetBSD 8.99.14 (GENERIC) #0: Sat Apr 21 23:01:29 UTC 2018 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64) no cloning interfaces are visible: gateway#

Re: Automated report: NetBSD-current/i386 test failure

On 24/04/2018 15:27, Martin Husemann wrote: On Mon, Apr 23, 2018 at 08:51:52AM +, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/ndp/t_ra:ra_basic [..] 2018.04.20.11.25.39 roy

Re: -current cloner interfaces broken/gone/unusable

Hi Tom On 24/04/2018 12:39, Tom Ivar Helbekkmo wrote: Thomas Klausner <t...@giga.or.at> writes: On Tue, Apr 24, 2018 at 08:56:48AM +0100, Roy Marples wrote: Saying this, from what I'm hearing this only happens at boot time, so we could potentially shrink the buffer back down again if w

Re: -current cloner interfaces broken/gone/unusable

On 24/04/2018 08:26, Martin Husemann wrote: On Tue, Apr 24, 2018 at 07:30:04AM +0200, Frank Kardel wrote: syslogd has sometimes issues with /var/run/log 2018-04-24T05:13:34.542548+00:00 gateway syslogd 408 - - recvfrom() unix `/var/run/log': No buffer space available This is a seaparate

Re: dhcpcd vs dhclient: part II (fxp0)

On 08/03/2018 14:50, John D. Baker wrote: I see this behavior with all fxp(4) interfaces under 'dhcpcd'. The carrier status from the interface bounces and causes 'dhcpcd' to repeatedly configure/unconfigure the interface. The workaround I use is to add: interface fxp0 nolink to my

Re: DHCP client: dhclient vs dhcpcd ?

On 02/02/2018 12:24, Riccardo Mottola wrote: does dhpcd share code/features with dhcpcd found on other systems beyond the name? Every feature bar one found in ISC dhclient can be found in dhcpcd. The one missing feature is the ability of the DHCP client to directly update a DNS server with

Re: DHCP client: dhclient vs dhcpcd ?

Hi Thomas On 01/02/2018 07:17, Thomas Mueller wrote: On Wed, Jan 31, 2018 at 1:18 PM, KIRIHARA Masaharu wrote: NetBSD has two DHCP clients; dhclient(8) and dhcpcd(8). What's the difference? Which is better to use? I'm biased as I maintain dhcpcd, but dhcpcd is better

Re: Crash related to VLANs in Oct 18th -current

On 24/10/17 23:34, Roy Marples wrote: On 24/10/17 23:30, Roy Marples wrote: On 24/10/17 13:27, Tom Ivar Helbekkmo wrote: Roy Marples <r...@marples.name> writes: This should only happen when dhcpcd is restarted. I just checked, and when I restart dhcpcd (from current, with your

Re: Crash related to VLANs in Oct 18th -current

On 24/10/17 23:30, Roy Marples wrote: On 24/10/17 13:27, Tom Ivar Helbekkmo wrote: Roy Marples <r...@marples.name> writes: This should only happen when dhcpcd is restarted. I just checked, and when I restart dhcpcd (from current, with your latest patch manually added), it correctl

Re: Crash related to VLANs in Oct 18th -current

On 24/10/17 13:27, Tom Ivar Helbekkmo wrote: Roy Marples <r...@marples.name> writes: This should only happen when dhcpcd is restarted. I just checked, and when I restart dhcpcd (from current, with your latest patch manually added), it correctly does a gratuitous arp announcement on the

Re: Crash related to VLANs in Oct 18th -current

On 23/10/2017 12:18, Roy Marples wrote: On 23/10/2017 11:28, Tom Ivar Helbekkmo wrote: Has something changed that makes dhcpcd now insist on listening to all interfaces (including the 802.1q trunk)? Yes. I will try and improve the logic so it's only the relevant interfaces. The change

Re: Crash related to VLANs in Oct 18th -current

On 23/10/2017 14:08, Thor Lancelot Simon wrote: > I think it is safe to say that an interface which is participating > in an interface stack such as vlan or agr should never be given an > address unless the user has explicitly configured the system to do > so. The sane default is to give

Re: Crash related to VLANs in Oct 18th -current

On 23/10/2017 11:28, Tom Ivar Helbekkmo wrote: > Has something changed that makes dhcpcd now insist on listening to all > interfaces (including the 802.1q trunk)? Yes. I will try and improve the logic so it's only the relevant interfaces. The change was made to allow IP address sharing on many

Re: Crash related to VLANs in Oct 18th -current

On 23/10/2017 07:42, Kengo NAKAHARA wrote: > Hi, > > On 2017/10/22 23:56, Tom Ivar Helbekkmo wrote: >> Tom Ivar Helbekkmo writes: >> >>> That did the trick! Thank you! :) > > Thank you for your testing! > >> I'm actually wondering if there may be something else strange

Re: Any actions regarding WPA2 vulnerabilities

On 16/10/2017 20:40, m...@netbsd.org wrote: On Mon, Oct 16, 2017 at 06:26:09PM +0200, Dmitry Salychev wrote: Hi, guys. Are there patches for these WPA2 vulnerabilities? Are there affected ports? I haven't seen any message regarding the subject. Thanks. Regards, - Dmitry Hi, We rely on

Re: -current vs MKINET6=NO

On 12/08/2017 06:09, Geoff Wing wrote: Hi, the following files need changes to build a full tree with MKINET6=NO external/apache2/mDNSResponder/dist/mDNSPosix/mDNSUNP.c external/bsd/dhcpcd/dist/src/dhcpcd.c external/bsd/dhcpcd/dist/src/if-bsd.c

Re: long delay getting address from ISP w/-current dhcpcd

Hi John On 24/07/2017 21:46, John D. Baker wrote: > On Mon, 24 Jul 2017, John D. Baker wrote: > >> Now that it has generated a new DUID (and once the ISP's DHCP server >> issues a lease for it), I'll need to be sure and copy the "duid" file >> as "/etc/dhcpcd.duid" for the netbsd-7 installation

Re: Seg Faults building devel/gobject-inspection with latest 8.0_BETA

On 21/06/2017 23:25, D'Arcy Cain wrote: On 06/21/17 17:02, D'Arcy Cain wrote: On 06/21/17 11:04, D'Arcy Cain wrote: #0 0x70e05a605663 in ?? () #1 0x70e05a200585 in ?? () from /usr/pkg/lib/libgthread-2.0.so.0 #2 0x70e0665e9b60 in ?? () #3 0x70e05a200669 in _fini () from

Re: HEADS-UP: /bin/sh memory management bug fixes committed

On 18/06/2017 00:22, Robert Elz wrote: Date:Sat, 17 Jun 2017 14:09:02 -0700 From:Alistair Crooks Message-ID:

Re: NetBSD-current amd64 with dhcpcd connects only par

On 14/06/2017 23:59, Robert Nestor wrote: > Not sure if this helps but noticed the user is using a cable modem connected > to Time Warner. I have the same type of connection on my amd64 system and > I’ve noticed similar issues of not always being able to get connected via > dhcp. And like the

Re: NetBSD-current amd64 with dhcpcd connects only partially

On 14/06/2017 03:03, Thomas Mueller wrote: > FreeBSD uses dhclient, which works when the driver is OK (re or rsu). Does this imply that on FreeBSD the driver sometimes fails? dhcpcd (an older version) is in the FreeBSD ports tree as well as another reference point - you could try that also. But

  1   2   >