Thanks Ken! :-)

Regards,
Glenn



On Thu, Oct 12, 2017 at 3:15 PM, <[email protected]> wrote:

>
>
> 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
>>
>>
>

Reply via email to