> On Oct 12, 2017, at 12:21 AM, Glenn Faustino <[email protected]> wrote: > > > Hi Ken, > > I updated my vultr vm to latest snapshot and the original issue was fixed but > when I reboot the machine the following was displayed in the console: > > [[email protected]:~]$ doas dmesg -s > doas ([email protected]) password: > Automatic boot in progress: starting file system checks. > /dev/sd0a (2719ba15e0dec7c1.a): file system is clean; not checking > /dev/sd0k (2719ba15e0dec7c1.k): file system is clean; not checking > /dev/sd0d (2719ba15e0dec7c1.d): file system is clean; not checking > /dev/sd0f (2719ba15e0dec7c1.f): file system is clean; not checking > /dev/sd0g (2719ba15e0dec7c1.g): file system is clean; not checking > /dev/sd0h (2719ba15e0dec7c1.h): file system is clean; not checking > /dev/sd0j (2719ba15e0dec7c1.j): file system is clean; not checking > /dev/sd0i (2719ba15e0dec7c1.i): file system is clean; not checking > /dev/sd0e (2719ba15e0dec7c1.e): file system is clean; not checking > setting tty flags > pf enabled > net.inet.ip.forwarding: 0 -> 1 > net.inet.gre.allow: 0 -> 1 > net.pipex.enable: 0 -> 1 > starting network > vio0: /var/db/dhclient.leases.vio0 line 17: expecting semicolon. > vio0: rebind > vio0: ^ > vio0: /var/db/dhclient.leases.vio0 line 19: expecting semicolon. > vio0: } > vio0: ^ > vio0: /var/db/dhclient.leases.vio0 line 20: unterminated lease declaration. > vio0: > vio0: ^
Mea culpa. This should already be fixed in -current. I missed a file in a commit. > vio0: RTM_DESYNC The fix for this has been identified (it’s not a dhclient bug! :-)) and should be committed shortly. .... Ken > vio0: DHCPDISCOVER - interval 1 > vio0: DHCPOFFER from 169.254.169.254 (fe:00:00:7c:b5:7b) > vio0: DHCPREQUEST to 255.255.255.255 > vio0: DHCPACK from 169.254.169.254 (fe:00:00:7c:b5:7b) > vio0: bound to 45.77.34.221 -- renewal in 43200 seconds > reordering libraries: done. > starting early daemons: syslogd pflogd rebound ntpd isakmpd npppd. > starting RPC daemons:. > savecore: no core dump > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd smtpd httpd spamd spamlogd sndiod. > starting local daemons: apmd cron. > Thu Oct 12 12:15:46 +08 2017 > > > Regards, > Glenn > > > >> On Tue, Oct 10, 2017 at 11:54 PM, Kenneth R Westerback >> <[email protected]> wrote: >> On Tue, Oct 10, 2017 at 03:28:39PM +0000, Anthony Coulter wrote: >> > I upgraded OpenBSD 6.1 to 6.2 on a Vultr node and after the first >> > reboot dhclient reports this new error: >> > >> > /var/db/dhclient.leases.vio0 line 15: Expecting CIDR prefix length. >> > option classless-static-routes 0.0.0.0/33 >> > ^ >> > >> > At this moment I both OpenBSD 6.1 and 6.2 are running on different >> > instances of Vultr nodes. Copying different versions of /sbin/dhclient >> > back and forth between my boxes shows that they're putting different >> > classless-static-routes lines in the leases file: >> > >> > option classless-static-routes 0.0.0.0/0 108.61.190.1, 169.254.169.254/32 >> > 108.61.190.1; >> > option classless-static-routes 0.0.0.0/33 108.61.190.1, 169.254.169.254/32 >> > 108.61.190.1; >> > >> > (The top line is created by a 6.1 dhclient executable; the bottom line >> > is created by 6.2.) >> > >> > Here's a tcpdump trace showing what happens when I renew my lease on >> > the server in question. Since "classless-static-routes" is option 121, >> > I was expecting to see a "79" (hex) somewhere in the response, but I >> > don't. So I have no idea where dhclient is getting the invalid mask >> > length from. >> > >> > # doas tcpdump -nXi vio0 port 67 and port 68 >> > tcpdump: listening on vio0, link-type EN10MB >> > 11:22:13.801668 108.61.190.203.68 > 255.255.255.255.67: xid:0xc9048474 >> > [|bootp] [tos 0x10] >> > 0000: 4510 0148 0000 0000 8011 0e8d 6c3d becb E..H........l=.. >> > 0010: ffff ffff 0044 0043 0134 57f1 0101 0600 .....D.C.4W..... >> > 0020: c904 8474 0000 0000 0000 0000 0000 0000 ...t............ >> > 0030: 0000 0000 0000 0000 5600 0035 275c 0000 ........V..5'\.. >> > 0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> > 0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> > 0060: 0000 0000 0000 ...... >> > >> > 11:22:13.803582 169.254.169.254.67 > 108.61.190.203.68: xid:0xc9048474 >> > Y:108.61.190.203 [|bootp] [tos 0xc0] >> > 0000: 45c0 0157 30df 0000 4011 c8f1 a9fe a9fe E..W0...@....... >> > 0010: 6c3d becb 0043 0044 0143 f7de 0201 0600 l=...C.D.C...... >> > 0020: c904 8474 0000 0000 0000 0000 6c3d becb ...t........l=.. >> > 0030: 0000 0000 0000 0000 5600 0035 275c 0000 ........V..5'\.. >> > 0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> > 0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> > 0060: 0000 0000 0000 ...... >> > >> > ^C >> > 170 packets received by filter >> > 0 packets dropped by kernel >> > >> > Regards, >> > Anthony Coulter >> > >> >> Argh. Need to read to end of email before replying. >> >> I'm looking into this. >> >> .... Ken >> >
