On 11/04/2021 19:19, Mayuresh wrote:
Such messages are appearing every 2 minutes 2s.
Apr 11 23:32:35 localhost dhclient[2032]: XMT: Solicit on vioif0, interval
110920ms.
Apr 11 23:34:27 localhost dhclient[2032]: XMT: Solicit on vioif0, interval
115560ms.
Apr 11 23:36:22 localhost dhclient[2032
On 03/01/2021 14:45, Greg Troxel wrote:
If the sending address site has set a strict DMARC configuration then
you basically have two options. One is to modify the headers and
forward it through the mailing list. Or two it can be discarded or
rejected. Forwarding a message from a sender site wi
On 20/10/2020 18:50, Steve Blinkhorn wrote:
Is there any way to access the MAC addresses of network interface
devices programmatically?
Call getifaddrs(3) and find the interface by ifa_name and family by
ifa_addr->sa_family == AF_LINK.
You can then cast ifa_addr to sockaddr_dl.
Use CLLADDR to
On 11/10/2020 11:42, Havard Eidnes wrote:
The question is whether we ought to do something to break this
circular dependency in our default install by specifying one or two
(depending on "minsane" and resiliency conciderations) ntp servers
via IP address? The issue then becomes "which IP address
On 12/08/2020 18:50, Mike Pumford wrote:
On 12/08/2020 18:29, Roy Marples wrote:
Maybe some other process is listening on the bootpc port?
If you stop dhcpcd and do `netstat -laf inet | grep bootpc` is anything listed?
That command produced no output when dhcpdc was stopped.
When dhcpcd is
On 12/08/2020 17:27, Mike Pumford wrote:
On 12/08/2020 17:04, Roy Marples wrote:
Interesting. You can post the output of `ps ax | grep dhcpcd` please?
12897 ? Is 0:00.75 dhcpcd: [master] [ip4] [ip6]
During all the IPv4 requests the IPv6 logic worked perfectly. I didn't see an
On 12/08/2020 13:43, Mike Pumford wrote:
On 11/08/2020 21:14, Mike Pumford wrote:
Aug 11 21:09:55 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 0xc8152c37),
next in 64.3 seconds
Aug 11 21:11:00 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 0xc8152c37),
next in 64.0 seconds
This cycl
On 10/08/2020 12:00, Mike Pumford wrote:
I've also noticed its intermittent. So its clearly being triggered by some
network activity.
dhcpcd will renew if the carrier goes down/up or you issue `dhcpcd -n` on the
command line. Those are the only early triggers.
Roy
Hi Mike
On 07/08/2020 17:03, Mike Pumford wrote:
Running 9.0-STABLE buit July 26th.
Machine is refreshing its least approximately once a minute. Despite the DHCP
server being configured with a lease time as follows:
max-lease-time 43200;
default-lease-time 43200;
Server is NetBSD 8.2-STABLE
On 20/06/2020 07:16, Dave McGuire wrote:
On June 20, 2020 12:01:40 AM Roy Marples wrote:
On 19/06/2020 23:08, Dave McGuire wrote:
On 6/19/20 5:09 PM, matthew sporleder wrote:
I personally think running such an old and inefficient computer is, literally,
immoral when a modern $30 machine can
On 19/06/2020 23:08, Dave McGuire wrote:
On 6/19/20 5:09 PM, matthew sporleder wrote:
I personally think running such an old and inefficient computer is, literally,
immoral when a modern $30 machine can emulate it perfectly using as much
electricity as a small CFL light bulb and leave over 700
On 21/02/2020 13:40, David Brownlee wrote:
- If you make a zfs filesystem on a disklabel partition (eg wd0f) and
the disk moves zfs does not seem to be able to find it again. If you
run MAKEDEV for the affected device into a new directory and point zfs
at that then it picks up the disk. This gave
On 17/02/2020 02:34, Edgar Pettijohn wrote:
On 02/16/20 20:31, Edgar Pettijohn wrote:
I'm trying to learn to use sqlite3 and I have encountered an oddity. I don't
have another system to test on at the moment. So I'm not sure if its me,
sqlite3, or netbsd. Either way. Here are the commands give:
On 13/02/2020 17:02, J. Hannken-Illjes wrote:
Please try again with Rev. 1.57 of
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c
Can we get that pulled up to -9 please?
Roy
I'm experimenting with ZFS on a new server.
Trying to get root on ZFS, but it's not working with device nodes.
Here are exact steps from the real root on FFS.
There is a zfs mount on /tank/ROOT.
# cd /tmp
# mknod null c 2 2
# echo test >null
# cd /tank/ROOT/tmp
# mknod null c 2 2
# echo test >nu
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 resul
On 07/05/2019 19:36, John D. Baker wrote:
On Sat, 4 May 2019, Roy Marples wrote:
I've imported dhcpcd-7.2.2 which fixes this issue.
After the pullup to netbsd-8 I ran a CVS update, built releases and
updated my systems. The NAT router has been working fine and the sparc
box booting
On 01/05/2019 13:55, John D. Baker wrote:
On Wed, 1 May 2019, Roy Marples wrote:
On 01/05/2019 03:44, John D. Baker wrote:
I've now tried it and it works as expected.
OK, this might be tricky to solve.
Can I get the output of route montior captured during early boot please?
To be
On 01/05/2019 13:55, John D. Baker wrote:
On Wed, 1 May 2019, Roy Marples wrote:
On 01/05/2019 03:44, John D. Baker wrote:
I've now tried it and it works as expected.
OK, this might be tricky to solve.
Can I get the output of route montior captured during early boot please?
To be
On 01/05/2019 13:55, John D. Baker wrote:
On Wed, 1 May 2019, Roy Marples wrote:
On 01/05/2019 03:44, John D. Baker wrote:
I've now tried it and it works as expected.
OK, this might be tricky to solve.
Can I get the output of route montior captured during early boot please?
To be
On 01/05/2019 03:44, John D. Baker wrote:
On Tue, 30 Apr 2019, John D. Baker wrote:
On Tue, 30 Apr 2019, Roy Marples wrote:
As to the need to bring the interface up, can you try reverting this
commit please?
https://roy.marples.name/git/dhcpcd.git/commit/?h=dhcpcd-7&am
On 30/04/2019 00:32, John D. Baker wrote:
After rebuilding with this patch and updating the router, it's remained
up for the last 4 hours which is much longer than before. Looks
promising.
Great!
As to the need to bring the interface up, can you try reverting this
commit please?
https://roy
Hi John.
It seems I didn't test this thoroughly enough as I was pressed with an
urgent matter with getting a new release in and I do appologise for that :(
This patch should help.
Let me know!
Roy
diff --git a/src/dhcp.c b/src/dhcp.c
index f24d14f6..8291dd23 100644
--- a/src/dhcp.c
+++ b/src/
On 24/04/2019 23:31, co...@sdf.org wrote:
The default Python version in pkgsrc is now 3.7, in preparation for
the coming end of life date of Python 2.7 (the previous default) at
the end of this year.
Can we punt 3.4, 3.5 and 3.6 then?
3.4 fails at least to build on netbsd-current due to an open
On 21/02/2019 17:02, triaxx wrote:
Le 2019-02-21 17:52, Roy Marples a écrit :
On 21/02/2019 16:45, triaxx wrote:
As least cisco respects -J but it doesn't fix the problem.
16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 576)
192.168.0.1.b
On 21/02/2019 16:45, triaxx wrote:
As least cisco respects -J but it doesn't fix the problem.
16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto
UDP (17), length 576)
192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok]
BOOTP/DHCP, Reply, length 548, xid 0xe090f
On 21/02/2019 16:18, triaxx wrote:
3 2019/01/16 5:55:46 PM info udhcpd[1154]: sending OFFER to
255.255.255.255 with 192.168.0.11
16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto
UDP (17), length 576)
192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok
On 21/02/2019 14:58, triaxx wrote:
Le 2019-01-18 17:54, Andy Ruhl a écrit :
On Fri, Jan 18, 2019 at 2:09 AM Roy Marples wrote:
Hi Fred
On 18/01/2019 06:05, triaxx wrote:
> I experienced a dhcpcd that cannot connect to a Cisco gateway
through a
> fresh NetBSD 8.0. I tried dhclient
Hi Fred
On 18/01/2019 06:05, triaxx wrote:
I experienced a dhcpcd that cannot connect to a Cisco gateway through a
fresh NetBSD 8.0. I tried dhclient which succeed.
I didn't see relevant diff between MAIN and netbsd-8.
I would like to send a PR but I'm interesting to know what informations
c
On 30/07/2018 15:38, Gua Chung Lim wrote:
So one of the changes in dhcpcd-7 was the default location of some
files, including the secret file which generates the SLAAC stable
private address. If you didn't change the location using postinstall(8)
before running dhcpcd it will have generated a new
On 29/07/2018 20:09, Robert Elz wrote:
Date:Sun, 29 Jul 2018 19:03:53 +0100
From:Roy Marples
Message-ID: <1718c621-40fe-cc05-5ec9-ee5f646de...@marples.name>
| > NetBSD 7 would have ignored the DHCP part, as there was no DHCPv6
| >
On 29/07/2018 18:38, Robert Elz wrote:
Date:Sun, 29 Jul 2018 23:05:01 +0700
From:Gua Chung Lim
Message-ID: <20180729160500.ga3...@gmail.com>
| I don't suspect my router,
| I don't suspect dhcpcd
| I don't suspect name resolution
|
| Any ideas?
Ne
On 29/07/2018 17:05, Gua Chung Lim wrote:
Thanks for your kind response.
* Martin Husemann (mar...@duskware.de) wrote:
In the not working case, wm0 has:
inet6 2405:9800:b550:2939:f234:69d6:e0bf:8ebf/64 flags 0x0
inet6 2405:9800:b550:2939:8638:35ff:fe48:5720/128 flags 0x0
and it would be
On 29/07/2018 09:06, Martin Husemann wrote:
In the not working case, wm0 has:
inet6 2405:9800:b550:2939:f234:69d6:e0bf:8ebf/64 flags 0x0
inet6 2405:9800:b550:2939:8638:35ff:fe48:5720/128 flags 0x0
and it would be good to understand where the second comes from.
Maybe add "-d" to dhcpcd_fla
On 16/07/2018 14:00, John D. Baker wrote:
"env force_hostname=YES" has it's own pitfall of flip-flopping in the same
way, but that's your adminsitrative decision based on your network setup.
Can "env var=value" be part of the block guarded by an "interface ifN"
statement? On a multi-homed mach
On 16/07/2018 04:17, John D. Baker wrote:
On Sun, 15 Jul 2018, John D. Baker wrote:
On Mon, 16 Jul 2018, Roy Marples wrote:
Sadly, all my machines are x86 based. I have an ERLITE mips router where I
also run dhcpcd, and it doesn't stamp on routes there either, so I'm pretty
sure
On 16/07/2018 01:27, John D. Baker wrote:
On Mon, 16 Jul 2018, Roy Marples wrote:
On 15/07/2018 23:54, John D. Baker wrote:
Possibly arrange for 'dhcpcd' to not touch the interface, but just
gather and set up the ancillary information requested/provided.
As of dhcpcd-7 at least t
On 15/07/2018 23:54, John D. Baker wrote:
On Sun, 15 Jul 2018, Roy Marples wrote:
But have we considered an alternative? The in kernel DHCP client as
I see it is just to handle network booting yes? Once userland is
netmounted, dhcpcd can then take over? If so, does the kernel DHCP
This seems
On 15/07/2018 12:16, Robert Elz wrote:
| The only other concern I have with this is that if we have two
| interfaces and dhcpcd receives the same short hostname on both but only
| a domain on one of them, then the hostname will flip-flop between short
| and long hostnames.
I'm not su
On 15/07/2018 11:18, Roy Marples wrote:
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that
need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or server config,
or ...) and then the client needs
> Every 30 days my machines loose the IPv6 prefix route.
This is being discussed on tech-net here:
http://mail-index.netbsd.org/tech-net/2016/08/05/msg006044.html
A workaround for dhcpcd has been posted here:
http://mail-index.netbsd.org/tech-net/2016/08/05/msg006045.html
Roy
42 matches
Mail list logo
