Re: NetBSD 9.1 VPS: Too many dhclient XMT: solicit messages
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]: XMT: Solicit on vioif0, interval 117380ms. Apr 11 23:38:20 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 119250ms. Apr 11 23:40:19 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 109500ms. Apr 11 23:42:09 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 124470ms. Apr 11 23:44:14 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110970ms. Anything to look out for? There is no DHCP (probably DHCPv6, but unsure) server on the other end of vioif0 or there is an issue with it replying like say a firewall. 2 minutes is quite a short upper limit for solicits - the RFC standard for both DHCP and DHCPv6 is one hour. I would advise using dhcpcd instead, but I doubt you'll see any different - maybe less noise in the logs by default. Roy
Re: postfix for 2 domains on 1 vps 1 ip
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 with strict DMARC set will be seen as a forgery by the recipient site receiving the mailing list and many sites, Google for one, will reject those messages. If valid DKIM is ok, then you have a third option: Do not modify the message. Specifically, do not add a subject tag and do not add a footer. I believe the NetBSD lists operate this way. I find the sender rewriting icky. If it rewrote to a per-user forwarding address at the mail host, so that sending to that address went only to the user, that would be ok, but combined with incorrect List Reply-To: it becomes all too easy for private replies to end up on lists. To me that is a bigger problem than just not allowing addresses with strict DMARC policies to be on lists :-) I think this is solved with ARC: https://dmarc.org/2019/07/arc-protocol-published-as-rfc-8617/ Roy
Re: MAC addresses
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 access the MAC address inside sockaddr_dl like so memcpy(mac, CLLADDR(sdl), sdl->sdl_alen); You can find an example here: http://anonhg.netbsd.org/src/file/ROY/external/bsd/dhcpcd/dist/src/if.c#l574 Roy
Re: ntpdate(8) and unbound(8) dependencies during boot
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(es)" and "how can that scale"? So the 50-ntp.conf dhcpcd hook script sets up ntp.conf with the IP addresses of NTP servers to use given from DHCP. If the ntp.conf file has changed as a result, the hook script will restart ntpd. If ntpd was passed the -g option to startup then it will ensure that the initial sync works no matter the state of the clock. We might want to consider adding -g to the default ntpd_flags. Roy
Re: dhcpcd refreshing lease very often.
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 running I see the following from that command: udp 0 0 *.bootpc *.* If you start dhcpcd again does the port then show? I'm guessing you are expecting the port number to show up in the ps output? Is that code in the 9.0-stable dhcpcd? Apart from the pid changing the ps output was identical: 6777 ? Ss 0:00.01 dhcpcd: [master] [ip4] [ip6] No, I was expecting an interface name. This should be working fine I'll try and spin up a netbsd-9 stable VM over the next few days and see if I can replicate. Roy
Re: dhcpcd refreshing lease very often.
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 any wm link events in the debug log and I can also check the logs in the managed switch the machine is attached to. Interesting. Maybe some other process is listening on the bootpc port? If you stop dhcpcd and do `netstat -laf inet | grep bootpc` is anything listed? If you start dhcpcd again does the port then show? Could you test net/dhcpcd from pkgsrc please? I'm curious if that fixes the issue. Yes but that might take me a little while. Thanks Roy
Re: dhcpcd refreshing lease very often.
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 cycle was finally stopped by this: Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: failed to renew DHCP, rebinding Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: expire in 5400 seconds Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 0x68dace9d), next in 3.0 seconds Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: acknowledged 192.168.1.2 from 192.168.1.9 Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: leased 192.168.1.2 for 43200 seconds Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: renew in 21600 seconds, rebind in 37800 seconds Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: writing lease `/var/db/dhcpcd/wm0.lease' So it looks like the renew code is not seeing and processing the ack from the server in the renew path. This will happen every renewal cycle so I can capture packet traces and share them if that helps. Just in case its relevent the client interface is configured as follows: wm0: flags=0x8843 mtu 1500 capabilities=7ff80 capabilities=7ff80 capabilities=7ff80 enabled=7ff80 enabled=7ff80 enabled=7ff80 ec_capabilities=17 ec_enabled=2 address: 10:c3:7b:95:20:ed media: Ethernet autoselect (1000baseT full-duplex) status: active Interesting. You can post the output of `ps ax | grep dhcpcd` please? Could you test net/dhcpcd from pkgsrc please? I'm curious if that fixes the issue. Roy
Re: dhcpcd refreshing lease very often.
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
Re: dhcpcd refreshing lease very often.
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 isc dhcpd and this is the only host of many on the network refreshing that often. Only non default option on the client is slaac hwaddr as I don't actually want the machine to have a privacy address as it just makes life hard from an RDNS perspective. Anything I need to look at to help with debugging this? You could start by adding the debug directive to dhcpcd.conf and restarting dhcpcd. Then examine syslog and see why it's refreshing so quickly - all the reasons should be logged. Roy
Re: Checking out src with Mercurial
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 emulate it perfectly using as much electricity as a small CFL light bulb and leave over 700mb of memory to spare. Sure, but it's, to put it simply, NOT THE REAL THING. If you don't get it, that's fine. Don't run one. But there's a massive difference between compiling and running. Cross compiles in NetBSD is what the base OS excells at. NetBSD used to run great directly on VAXen. On real hardware. That's literally what I just said! Do I run NetBSD on my ERLITE? YES! Do I compile on my ERLITE? NO! It's also not memory that's the concern. It's just too slow and more efficient to offload that task to a more capable machine. My ERLITE is in constant use 24 hrs a day and is super rock solid, thanks to NetBSD. Roy
Re: Checking out src with Mercurial
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 700mb of memory to spare. Sure, but it's, to put it simply, NOT THE REAL THING. If you don't get it, that's fine. Don't run one. But there's a massive difference between compiling and running. Cross compiles in NetBSD is what the base OS excells at. A case in point - updating my ERLITE is a fairly quick operation. I compile everything on my AMD 2600x w 32G ram. It wasn't that long ago that it look longer to unpack to the internal USB than it did to build the binaries on another host! But thanfully skrll@ solved that. My ERLITE also runs dnsmasq and while it's quite tiny, it still takes an age to build. Roy
Re: ZFS status
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 me something of a scare. zfs best practice is to use raw devices, so this shouldn't be an issue for most people I hit with issue with my experiments with the Root On ZFS ramdisk. Coupled with the fact that the ramdisk needs the FFS boot partiton to be labelled makes GPT a must have. Roy
Re: [*EXT*] sqlite3 issues
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:
laptop$ /usr/bin/sqlite3 test.db
SQLite version 3.26.0 2018-12-01 12:34:55
Enter ".help" for usage hints.
sqlite> CREATE TABLE os_groups (
...> os_group INTEGER PRIMARY KEY,
...> os_type TEXT NOT NULL
...> );
sqlite> INSERT INTO os_groups (os_type)
...> VALUES
...> ('BSD'),
...> ('LINUX'),
...> ('other');
sqlite> CREATE TABLE os (
...> os_id INTEGER PRIMARY KEY,
...> os_name TEXT NOT NULL,
...> os_group INTEGER,
...> FOREIGN KEY (os_group)
...> REFERENCES os_groups (os_type)
...> ON UPDATE SET NULL
...> ON DELETE SET NULL
...> );
sqlite> INSERT INTO os (os_name, os_group)
...> VALUES('NetBSD', 1);
sqlite> INSERT INTO os (os_name, os_group)
...> VALUES('Slackware', 2);
sqlite> INSERT INTO os (os_name, os_group)
...> VALUES('Winders', 3);
sqlite> DELETE FROM os_groups WHERE os_group = 3;
sqlite> SELECT * FROM os;
1
2
3
I was expecting the `3
The os_group should have been set to NULL.
NetBSD laptop 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Thanks,
Edgar
Not sure why but the last bit got eaten along the way.
sqlite> select * from os;
1|NetBSD|1
2|Slackware|2
3|Winders|3
I was expecting the `3|Winders|3' to look like `3|Winders|'.
Have you enabled foreign key support at the application?
https://www.sqlite.org/foreignkeys.html
sqlite> PRAGMA foreign_keys = ON;
Roy
Re: ZFS chroot cannot open dev nodes
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
ZFS chroot cannot open dev nodes
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 >null -sh: cannot create null: error 22 Any clue as to why? zfs gets devices shows that every mount has it set to on and mount does not report the nodev option, so it *should* work. What am I missing? Does anyone else see this? This is NetBSD-9.0_RC2 if that helps. Roy
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 resulting sluggishness. https://nxr.netbsd.org/xref/src/sys/net/rtsock_shared.c#1602 I would imagine that if an interface is interupting that much then it's constantly sending messages to route(4) to say that it's up/down and addresses are detached/tentative in a tight loop. The queueing mechanism has a fixed length and while we go out of our way to notify userland if there's an error sending these messages, we can't send this one at all so we just log it. So it's an artifact of your interupt storm, but not the cause. Roy
Re: regression w/latest dhcpcd?
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 from local disk configures "le0" without needing any additions to "/etc/ifconfig.le0". Excellent news :)
Re: regression w/latest dhcpcd?
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 clear, your asking about a 'dhcpcd' binary built without reverting the commit you mentioned, correct? When it fails, is the interface marked IFF_UP? Before reverting that commit, the output of 'ifconfig le0' showed it marked "UP". Watching the logfiles on the DHCP server showed no requests coming in from that host when booting from disk. When booting from network, I could see all three phases (bootloader, kernel, "/etc/rc.d/network" ['dhcpcd']). I've imported dhcpcd-7.2.2 which fixes this issue. Roy
Re: regression w/latest dhcpcd?
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 clear, your asking about a 'dhcpcd' binary built without
reverting the commit you mentioned, correct?
When it fails, is the interface marked IFF_UP?
Before reverting that commit, the output of 'ifconfig le0' showed it
marked "UP".
Watching the logfiles on the DHCP server showed no requests coming in
from that host when booting from disk. When booting from network, I
could see all three phases (bootloader, kernel, "/etc/rc.d/network"
['dhcpcd']).
OK. I strongly suspect this is because the driver reports IFM_AVALID via
SIOCGIFMEDIA but then doesn't announce link state changes via route(4).
This is very much driver dependant sadly and we have no way of knowing
this little detail. Basically this is a poor driver :(
The attached patch works around this by calling SIOCGIFMEDIA when
RTM_IFINFO reports an unknown link status.
Let me know how it works for you!
Roy
diff --git a/src/dhcpcd.h b/src/dhcpcd.h
index 24782cbc..3e35a3de 100644
--- a/src/dhcpcd.h
+++ b/src/dhcpcd.h
@@ -85,7 +85,6 @@ struct interface {
unsigned short vlanid;
unsigned int metric;
int carrier;
- bool media_valid;
bool wireless;
uint8_t ssid[IF_SSIDLEN];
unsigned int ssid_len;
diff --git a/src/if-bsd.c b/src/if-bsd.c
index 20467dfc..dd74c2d7 100644
--- a/src/if-bsd.c
+++ b/src/if-bsd.c
@@ -203,6 +203,28 @@ if_closesockets_os(struct dhcpcd_ctx *ctx)
close(priv->pf_inet6_fd);
}
+static int
+if_carrier_flags(struct interface *ifp, unsigned int flags)
+{
+ struct ifmediareq ifmr = { .ifm_status = 0 };
+
+ strlcpy(ifmr.ifm_name, ifp->name, sizeof(ifmr.ifm_name));
+ if (ioctl(ifp->ctx->pf_inet_fd, SIOCGIFMEDIA, &ifmr) == -1 ||
+ !(ifmr.ifm_status & IFM_AVALID))
+ return flags & IFF_RUNNING ? LINK_UP : LINK_UNKNOWN;
+
+ return (ifmr.ifm_status & IFM_ACTIVE) ? LINK_UP : LINK_DOWN;
+}
+
+int
+if_carrier(struct interface *ifp)
+{
+
+ if (if_getflags(ifp) == -1)
+ return LINK_UNKNOWN;
+ return if_carrier_flags(ifp, ifp->flags);
+}
+
static void
if_linkaddr(struct sockaddr_dl *sdl, const struct interface *ifp)
{
@@ -987,19 +1009,20 @@ if_ifinfo(struct dhcpcd_ctx *ctx, const struct if_msghdr
*ifm)
{
struct interface *ifp;
int link_state;
+ unsigned int flags;
if ((ifp = if_findindex(ctx->ifaces, ifm->ifm_index)) == NULL)
return;
+ flags = (unsigned int)ifm->ifm_flags;
switch (ifm->ifm_data.ifi_link_state) {
case LINK_STATE_UNKNOWN:
- if (ifp->media_valid) {
- link_state = LINK_DOWN;
- break;
- }
- /* Interface does not report media state, so we have
-* to rely on IFF_UP. */
- /* FALLTHROUGH */
+ /* In theory this is only set when an interface is first
+* initiaised.
+* However whilst some drivers report an active link
+* via SIOCGIFMEDIA, they don't bother to announce it
+* via a routing message. */
+ link_state = if_carrier_flags(ifp, flags);
case LINK_STATE_UP:
link_state = ifm->ifm_flags & IFF_UP ? LINK_UP : LINK_DOWN;
break;
@@ -1008,8 +1031,7 @@ if_ifinfo(struct dhcpcd_ctx *ctx, const struct if_msghdr
*ifm)
break;
}
- dhcpcd_handlecarrier(ctx, link_state,
- (unsigned int)ifm->ifm_flags, ifp->name);
+ dhcpcd_handlecarrier(ctx, link_state, flags, ifp->name);
}
static void
diff --git a/src/if.c b/src/if.c
index efc4314c..28597dc2 100644
--- a/src/if.c
+++ b/src/if.c
@@ -126,65 +126,37 @@ if_closesockets(struct dhcpcd_ctx *ctx)
}
int
-if_carrier(struct interface *ifp)
+if_getflags(struct interface *ifp)
{
- int r;
- struct ifreq ifr;
-#ifdef SIOCGIFMEDIA
- struct ifmediareq ifmr;
-#endif
+ struct ifreq ifr = { .ifr_flags = 0 };
- memset(&ifr, 0, sizeof(ifr));
strlcpy(ifr.ifr_name, ifp->name, sizeof(ifr.ifr_name));
- r = ioctl(ifp->ctx->pf_inet_fd, SIOCGIFFLAGS, &ifr);
- if (r != -1)
- ifp->flags = (unsigned int)ifr.ifr_flags;
-
-#ifdef __sun
- return if_carrier_os(ifp);
-#else
- if (r == -1)
- return LINK_UNKNOWN;
-
-#ifdef SIOCGIFMEDIA
- memset(&ifmr, 0, sizeof(ifmr));
- strlcpy(ifmr.ifm_name, ifp->name, sizeof(ifmr.ifm_name));
- if (ioctl(ifp->ctx->pf_inet_fd,
Re: regression w/latest dhcpcd?
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 clear, your asking about a 'dhcpcd' binary built without reverting the commit you mentioned, correct? Shouldn't matter. We're looking for is RTM_INFO. Here's an example: RTM_IFINFO: iface status change: len 152, if# 1, carrier: unknown, flags: 0x8842 During inital boot, interfaces set their carrier to unknown and then to either down / up when they finally get around to working it out. Also, when the interface is marked up, flags should have UP reported in the message as well. Roy
Re: regression w/latest dhcpcd?
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&id=4f903d6ad4adf2de7712d36a921051b4dfd7210a I've rebuilt a release for sparc with this patch (and the prior one) but have not had a chance to try it yet. 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? Maybe this will work $ cat /etc/dhcpcd.enter-hook # Log routing socket diagnositics if [ "$reason" = PREINIT ] && [ "$interface" = le0 ]; then route -n monitor >/var/log/rtsock.log & fi When it fails, is the interface marked IFF_UP? Roy
Re: regression w/latest dhcpcd?
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.marples.name/git/dhcpcd.git/commit/?h=dhcpcd-7&id=4f903d6ad4adf2de7712d36a921051b4dfd7210a I've had a similar report from an OpenBSD user that reverting this helps, but it's needed for wireless to work in early boot. At least for the wireless cards I have. Roy
Re: regression w/latest dhcpcd?
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/dhcp.c
@@ -3499,6 +3499,11 @@ dhcp_readudp(struct dhcpcd_ctx *ctx, struct interface
*ifp)
logerr(__func__);
return;
}
+ if (D_CSTATE(ifp) == NULL) {
+ logdebugx("%s: received BOOTP for inactive interface",
+ ifp->name);
+ return;
+ }
}
dhcp_handlebootp(ifp, (struct bootp *)buf, (size_t)bytes,
Re: pkgsrc python default version -> 3.7
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 openssl conflict by the looks of it. Roy
Re: dhcpcd failure
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.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261 So it's now broadcast which is good. Does dhcpcd not see that? Roy > No, it does not. Does it log anything about a reply with the debug flag set? -d
Re: dhcpcd failure
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 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261 So it's now broadcast which is good. Does dhcpcd not see that? Roy
Re: dhcpcd failure
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] BOOTP/DHCP, Reply, length 548, xid 0x66ec8de4, Flags [none] (0x) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" What cisco says it's doing and what it's actually doing are different. It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is correct) but in reality it's unicasting to 192.168.0.11. I don't see how any DHCP client can work with that. You might try getting dhcpcd to send the broadcast option using the -J flag. That's non standard though and I doubt it will fix the issue. Roy
Re: dhcpcd failure
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 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 > could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. If it really is a Cisco compliance issue, I'd like to see a wireshark of the failing request and the successful one for my own amusement. This command seems to work on my mac, I'm guessing it will be similar on NetBSD except the interface name: tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap Andy tcpdump is like the observer of the Schrödinger's cat, it interfere in measurement. If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running service -v dhcpcd restart, it works fine... Then, I can just provide the packet trace when the request succeed: 14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318 14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325 14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319 14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 Looks to me like the DHCP client is broadcasting for a lease (ie it doesn't have an IP address) but the DHCP server thinks it has an IP address and is unicasting to something that doesn't exist? Can you add more - to see if the client is giving any hints if it has an ip address? Roy
Re: dhcpcd failure
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 could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. Roy
Re: High latency for IPv6 on netbsd-8
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 secret (and duid) file which would result in different addresses being defined on the interface. This could be an issue as well. It seems likely. Please tell me the old and new file locations. Old locations: /etc/dhcpcd.duid /etc/dhcpcd.secret New locations: /var/db/dhcpcd/duid /var/db/dhcpcd/secret You can add `nodhcp6` to dhcpcd.conf to disable DHCP6 entirely. I have done it. % tail -n 2 /etc/dhcpcd.conf logfile /var/log/dhcpcd.log nodhcp6 Now ping6 is usable even if DHCP6 is disabled entirely. Does this imply that it's all now working for you? So the only other think to check would be /etc/resolv.conf to see if it still lists the IPv6 DNS server. I suspect not as not many RA's carry RDNSS options. Roy
Re: High latency for IPv6 on netbsd-8
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 | > client there | | That's not true. I phrased what I said badly. From earlier messages it is clear that the NetBSD 7 host in question (when it was running NetBSD 7) was using dhclient and rtsol (and kernel IPv6 addr autoconf). On that particular netbsd-7 host there was no DCHCPv6 client, ... | NetBSD 7 shipped with dhcpcd-6.4.3 which did have a functional DHCPv6 | client. OK, but it was not the default, and few sites used it. sysinst(8) installed dhcpcd as the default DHCP client in -7. So I would argue it was the default. In -5, ifconfig_bge0=dhcp would start dhcpcd as well, so I would argue that it's been the default dhcp client for longer than you think. For fresh installs at least. Upgrades would continue using whatever they had set previously which would have been dhclient. | While I wont rule out this problem could be a dhcpcd issue, currently nothing | points to that being the case. Agreed, but right now nothing points to anything being the cause. Clearly something odd is happening, and I suspect that there might be some clue in some information that is not yet available. | 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 Since dhcpcd was not being used previously there would have been no old files to worry about, it would all be new. And the address will have changed, as now one of the randomly generated private addresses is clearly being used, whereas previously it was most likely an EUI-64 based one. | You can add `nodhcp6` to dhcpcd.conf to disable DHCP6 entirely. | This should ignore both the RA O and M flags and probably any static | DHCP6 setup you might have installed as well, unless a following dhcp6 | option re-enables it. Does that also affect the SLAAC stable address generation (autoconf'd addr on the advertised prefix) ?If it doesn't, that would be worth trying. Disabling DHCP6 in dhcpcd has no effect on any address generated from the RA. Roy
Re: High latency for IPv6 on netbsd-8
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? NetBSD 7 would have ignored the DHCP part, as there was no DHCPv6 client there That's not true. NetBSD 7 shipped with dhcpcd-6.4.3 which did have a functional DHCPv6 client. Now an awful lot of RA and DHCP6 issues have since been fixed, and -8 (and the next non teeny -7 release) ship with dhcpcd-7.0 which has currently zero reported issues as yet. While I wont rule out this problem could be a dhcpcd issue, currently nothing points to that being the case. Is the DHCP server in the router? If so, one possibility is that when it assigns an address to a client host, it expects the client to use that address, and not something else. Your NetBSD-8 host is using its autoconfigured address, and ignoring (though configuring) the DHCP assigned one. The router might be dropping packets either from, or to, the autoconfigured address. 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 secret (and duid) file which would result in different addresses being defined on the interface. This could be an issue as well. In any case, there is lots more that can be done. And perhaps Roy can suggest some options for dhcpcd which would make it ignore the "use DHCP" in the RA or ignore the "autoconfigure using this prefix" so you could try each of those (if it can be done) and see if one helps. You can add `nodhcp6` to dhcpcd.conf to disable DHCP6 entirely. This should ignore both the RA O and M flags and probably any static DHCP6 setup you might have installed as well, unless a following dhcp6 option re-enables it. Roy
Re: High latency for IPv6 on netbsd-8
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 good to understand where the second comes from. Maybe add "-d" to dhcpcd_flags in /etc/rc.conf and see what it says? -d flag when ping6 is NOT working, Excerpted from /var/run/rc.log. https://pastebin.com/JXkKxuSc -d flag when ping6 is working, # /etc/rc.d/dhcpcd stop (then leave it 5-6 seconds) # /etc/rc.d/dhcpcd start https://pastebin.com/iu4utd9y % uname -a NetBSD netbsd 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #1: Sat Jul 28 08:47:57 +07 2018 root@netbsd.localdomain:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 For now, my only workaround is to repeat restarting the router until ping6 works, and without touching any configuration on netbsd-8. I don't suspect my router, as the other machines on the same LAN (including the previous netbsd-7) are still working pretty fine. I don't suspect dhcpcd as both inet and inet6 got assigned. And I don't suspect name resolution as it can always interpret canonical names into numeric addresses for both inet and inet6. Any ideas? rc.log will only log what happens until dhcpcd forks. In the first log, dhcpcd forks when the DHCPv6 DaD completes. This would be due to the RA not carrying a RDNSSL option. The the second log, dhcpcd forks when the right away because DaD has already completed on the existing address. We've not yet received an RA at this point. You'll get better information either by trawling syslog, or by adding `logfile /var/log/dhcpcd.log` to dhcpcd.conf. Hopefully you'll see the same debug written - just maybe not in the same order due to randomised delays. Roy
Re: High latency for IPv6 on netbsd-8
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_flags in /etc/rc.conf and see what it says? Oh that's easy. The second address has a /128 prefix which means it's come from a DHCP6 server. DHCP6 only hands out addresses which are not tied to any specific prefix (DHCP6 has no notion of prefixes, RA is used for that). dhcpcd does not request DHCP6 by default unless it receives a RA with the M or O bit set. With M dhcpcd requests an address, with O dhcpcd just requests other information (everything but an address). Roy
Re: FQDNs for netbooted hosts via DHCP?
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 machine, there should be only one host name and one can choose the interface from which it receives (and acts on) the information. Yes it can be guarded like so and I can't believe I didn't think of that! I blame it on Monday. I only tried DHCP configuration of multiple interfaces a long time ago. I found it wasn't a workable solution for me, but I forget what the specific problems were. I think it was my NAT router and I wanted the bulk of the network setup (and ancillary information like name servers and ntp servers, etc.) to be taken from the internal interface, and only the public IP and default route set for/from the external interface. Perhaps I'll revisit that when I don't mind the service interruption. These days it should just work. Each interface is assigned a metric - it's fairly simplistic: P2P > ETHERNET > WIFI then it's split on interface index number. Of course this can be customised in dhcpcd.conf Lowest metric takes precedence. If you wanted to be really clever, you could assign the same IP to wired and wireless interfaces and dhcpcd will swap the IP over seemlessly. Roy
Re: FQDNs for netbooted hosts via DHCP?
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 this isn't an arch issue ... but I could be wrong. The only route that was an issue was the local route to the NFS server. Somehow a netbooted x86 system can complete the configuration, but non-x86 dies as soon as 'dhcpcd' (or the earlier 'dhclient') touches the interface. Interface is downed, root file system is gone, can't bring interface back up, game over. I've got a fresh build of -current just installed for the netbooted Lemote YeeLoong. Need to give it a whirl with "dhcp" in the "ifconfig.rtk0" file and see if the situation has changed. Well, what do you know! The YeeLoong successfully used 'dhcpcd' upon netbooting. And with "env force_hostname=YES", it gets an FQDN instead of its short name (only). And a SPARCstation 5 netbooting -8 has just done the same. Looks like a winner. Great news! After thinking about it some more, I think the best solution for the FQDN is to either fix the DHCP server to send the domain in the hostname field OR stop the kernel assigning a hostname OR leave things as they are. I don't feel comfortable changing dhcpcd here because it now has the potential to flip-flop the hostname in a badly configured environment AND override the users default choice of setting a short hostname in rc.conf. "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. BTW, sending the FQDN in the hostname option is RFC compliant but I understand your frustrations because there is no easy way to do that in your DHCP server. Anyone have any preference on a course of action here? Roy
Re: FQDNs for netbooted hosts via DHCP?
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 that should no longer be the case. So -current and -8, dhcpcd won't touch pre-existing routes if it doesn't need to. I don't recall you saying what NetBSD or dhcpcd version you were using. All hosts that can netboot run -current as such. All but a dwindling few run -8 from local disk. Some also have -8 via netboot/NFS and a couple still have -6 on NFS. Anything not yet running -8 likely has -7 until I can get around to updating it. sparc is the most frequently used non-x86 platform. evbarm-earmv7hf (-8), evbmips-mips64el, macppc, and sparc64 (all -current) make appearances from time to time. There are a few others about (various m68k boxen and one PReP), but arranging for them to run is a lot of work right now. I will have to arrange to try one of the non-x86en with 'dhcpcd' under netboot/NFS conditions. It's been a long time since I tried and the last time things behaved as I described. 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 this isn't an arch issue ... but I could be wrong. Roy
Re: FQDNs for netbooted hosts via DHCP?
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 to be a condition unique to x86 platforms, that one can re-configure the network interface with 'dhcpcd' (and in the past, 'dhclient') on a netbooted host. All the non-x86 platforms I've tried this with hang (NFS error 69) when the network interface is reconfigured. 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 that should no longer be the case. So -current and -8, dhcpcd won't touch pre-existing routes if it doesn't need to. I don't recall you saying what NetBSD or dhcpcd version you were using. Roy
Re: FQDNs for netbooted hosts via DHCP?
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 sure I see that (and in any case that kind of server mis-config is likely to cause issues anyway) but I will accept your more experience in this area. And no, we would not want that. | This is probably unlikely, but is worth pointing out. The way I see it, the best way of fixing this is to improve the in kernel dhcp client to set the fqdn using hostname + domain and control the default behaviour via sysctl (I do agree with kre that FQDN should be the default). 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 client even need to set the hostname? If not, we can remove that to make the kernel smaller. Roy
Re: FQDNs for netbooted hosts via DHCP?
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 server
config,
or ...) and then the client needs to "do the right thing" with the
data that is
returned.
Lastly, for this, I wonder if perhaps that final "false" in need_hostname
(in dhcpcd-hooks/30-hostname) might instead be something more like
${hfqdn} && [ "${hostname}" = "${hostname#*.}" ]
If we're going to test that, then we need to check the converse for
${hsort} && [ "$hostname" = "${hostname%%.*}" ]
The actual change required is a bit more invasive than that line change
though, but it suffices for this discussion.
Patch here:
http://www.netbsd.org/~roy/dhcpcd-hostname-promotion.diff
Please test and let me know if it works for you!
Roy
Re: FQDNs for netbooted hosts via DHCP?
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 to "do the right thing" with the data that is
returned.
Lastly, for this, I wonder if perhaps that final "false" in need_hostname
(in dhcpcd-hooks/30-hostname) might instead be something more like
${hfqdn} && [ "${hostname}" = "${hostname#*.}" ]
If we're going to test that, then we need to check the converse for
${hsort} && [ "$hostname" = "${hostname%%.*}" ]
The actual change required is a bit more invasive than that line change
though, but it suffices for this discussion.
so that (If I got that correct) if we want a FQDN as the hostname, and
what has been set (by something else) is not a FQDN but just a short
name, then we allow dhcpcd to set the FQDN (overriding whatever was
set before). If it had been this way, the force_hostname stuff would not
have been needed.
If that change is mde though it would need to be made clear that
(as the default is to set a FQDN) that simply setting a short hostname
in rc.conf would not be effective, dhcpcd.conf would also need to be
modified to allow short names if the DHCP server returns names.
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.
This is probably unlikely, but is worth pointing out.
Roy: I'd also suggest getting rid of the '-a' operator in test arg lists,
while it is probably OK in all systems as used, it is not really
safe - test with more than 4 args (not counting the ']' when present)
produces unspecified results. Use && instead. There are two of
them in that script (well, the same one, more or less, in
need_hostname() and set_hostname())
You're referring to this?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
>4 arguments:
The results are unspecified.
Well, Today I Learned something new I guess.
I suppose my only concern is speed ... that would not produce any more
subshells on NetBSD or any modern shell would it? Guess I should do some
testing around that.
Roy
Re: 7.0 loosing IPV6 prefix route after 30 days
> 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
