Messages

@franco, that might be the fastest I've ever seen a patch generated for anything, ever.

Thankfully it's a fairly clear edge case and just a little cleanup will make sure it doesn't happen again.

Thank you!  Amazing especially on the cusp of a major release!

OK, so I went ahead and tried removing /var/etc/radvd.conf altogether.

Guess what?  Works perfectly now.  dhcp6c starts right up on boot, prefixes are allocated to the various VLANs correctly, all looks perfect.

I think, perhaps, I see how we ended up with a rogue radvd.conf.

Here's what I did and how I think we got there:

Step 1 - Wipe DEC2752
Step 2 - Fresh install 25.7
Step 3 - Restore A10-gen3-config.xml to get proper tunables etc.
    *** This has igc0 assigned as the LAN interface. ***
Step 4 - Restore my DEC2752 backup on top of the A10-gen3-config.xml
   --> I have radvd disabled, but I believe the radvd.conf was ALREADY generated by the A10-gen3-config.xml, and wasn't "cleaned up" when igc0 was deassigned.
Step 5 - Orphaned radvd.conf was in /var/etc, but since radvd is disabled, it was never overwritten with a 'clean' copy.

So I think that's how we got a /var/etc/radvd.conf that referenced igc0, which it shouldn't as that's now the WAN interface.

Odd scenario for sure.   Just wondering as more of us move from ISC/KEA+radvd to straight dnsmasq, if there's a way to 'scrub' the radvd config?

[unchecked]

What I don't understand is that there are actually two ways dhcp6c is started: once immediately and once per rtsold. 25.7.11 decouples the starts of both so they don't race to the finish line together, but OTOH that was never really the case and only the side effect that the second one would release the IP of the first one and try again (and sometimes fail because the ISP says no to the second request).

You can just start via "/var/etc/rtsold_wan_script.sh igb1" normally which is how the system does it.  "wan" and "igb1" may be different for you.

The other thing is to check /var/etc/dhcp6c.conf if the configuration for "igb1" is actually there or not. In the worst case it's not there when it decides to start which means it may exit as soon as it was started and then it looks like it wasn't started. If not some code path decided that it's simply not ready (or misconfigured).


Cheers,
Franco

So - I don't seem to have that script (at least, not with an interface assignment name in it -- see the two scripts below):

Code Select Expand

[root@dmurphy-gw /var/etc]# ls -l *sh
-rwxr-xr-x  1 root wheel 1355 Jan 19 23:35 dhcp6c_wan_script.sh
-rwxr-xr-x  1 root wheel 1041 Jan 19 23:35 rtsold_script.sh
[root@dmurphy-gw /var/etc]#

Contents of /var/etc/dhcp6c.conf here - all of which look at least nominally correct to me.

Code Select Expand

root@dmurphy-gw:~ # cat /var/etc/dhcp6c.conf
interface igc0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/56 infinity;
  prefix-interface lagg0_vlan77 {
    sla-id 2;
    sla-len 8;
  };
  prefix-interface lagg0 {
    sla-id 1;
    sla-len 8;
  };
  prefix-interface lagg0_vlan91 {
    sla-id 3;
    sla-len 8;
  };
};

Now, this may be where things are getting interesting.

I've migrated 100% over to dnsmasq - not running ISC or KEA, and (perhaps crucially) - not radvd.

That said, for whatever reason, "Router Advertisements" was unchecked in my dnsmasq configuration, too.

That was very much not intentional - I could've sworn that was enabled.  Not sure if it matters one way or another, but I turned on the RA setting in dnsmasq, and then did want to verify that /var/etc/radvd.conf exists - it does, and it also appears (nominally) correct:

Code Select Expand

root@dmurphy-gw:~ # cat /var/etc/radvd.conf
# Automatically generated, do not edit
# Generated RADVD config for dhcp6 assignment from wan on lan
interface igc0 {
        AdvSendAdvert on;
        AdvLinkMTU 1500;
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        DNSSL localdomain { };
};

So after a fresh reboot, I see that rtsold is running, looks like it's hooked the correct scripts, but dhcp6c never starts.

Code Select Expand

root@dmurphy-gw:~ # ps auxwww|grep -i rtsol
root    78062   0.0  0.0   13924   2552  -  SCs  23:51   0:00.13 /usr/sbin/rtsold -aiu -p /var/run/rtsold.pid -A /var/etc/rtsold_script.sh -R /usr/local/opnsense/scripts/interfaces/rtsold_resolvconf.sh -D
root    79643   0.0  0.0   13924   2504  -  Is   23:51   0:00.03 rtsold: rtsold.llflags (rtsold)
root    80526   0.0  0.0   13924   2504  -  Is   23:51   0:00.00 rtsold: rtsold.script (rtsold)
root    81395   0.0  0.0   13924   2496  -  Is   23:51   0:00.00 rtsold: rtsold.sendmsg (rtsold)
root    81902   0.0  0.0   13924   2616  -  Ss   23:51   0:00.01 rtsold: system.syslog (rtsold)
root     7004   0.0  0.0   13744   2416 u2  S+   23:53   0:00.00 grep -i rtsol
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ # ps auxwww|grep -i dhcp
root     7612   0.0  0.2   29944  18272  -  Ss   23:51   0:00.57 /usr/local/bin/python3 /usr/local/opnsense/scripts/dhcp/unbound_watcher.py --domain home (python3.11)
root    47467   0.0  0.0   14504   2656  -  Is   23:52   0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP -B 98.111.111.111 -p /var/run/dpinger_WAN_DHCP.pid -u /var/run/dpinger_WAN_DHCP.sock -s 1s -l 4s -t 60s -d 1 1.1.1.1
_dhcp   76103   0.0  0.0   14080   2816  -  SCs  23:51   0:00.00 dhclient: igc0 (dhclient)
root    12022   0.0  0.0   13744   2416 u2  S+   23:53   0:00.00 grep -i dhcp

I still have to run it by hand.  Trying to run "/var/etc/rtsold_script.sh igc0" just results in "Rejecting own configuration" as it finds igc0 in /var/etc/radvd.conf (see logic in the rtsold_script.sh)

So without deeper knowledge, I guess the question is --- should /var/etc/radvd.conf contain an igc0 stanza for WAN? And is it correct?  Or should I remove it altogether (what generates it if radvd is disabled?)

Very similar to the issue I have with dnsmasq.  Continually growing memory region until it consumes all the available memory.

I created a cron entry to restart dnsmasq every morning at 1am; that has gotten me 'over the hump' so to speak.

But there is for sure a memory leak somewhere in dnsmasq; unfortunately we don't have the right bits turned on to enable dtrace in the freebsd base... it would help narrow this down for sure.  (Long live Sun Microsystems!)

I don't think there are structural issues that would warrant this behaviour. Very rarely I see that dhcp6c is not starting, but that's because e.g. the port it's being run over is not plugged in for example.

There are logs and context missing here. 26.1 would not change what is described here. We're relying on the same mechanism to start the dhcp6c service which works IMO.


Cheers,
Franco

Then I'll do some more digging and see if I can identify why dhcp6c isn't starting.  My WAN connection (Verizon Fios) is dual-stacked and comes up fine on IPv4; has no issue grabbing and holding its IP.

As usual I'm sure it's a misconfiguration on my part somewhere; just not entirely sure what I'd misconfigure as the DHCPv6 configuration is very basic on the WAN interface:

Generic Configuration
  - IPv6 Configuration Type: DHCPv6
DHCPv6 client configuration
  - Use VLAN priority: Disabled
  - Configuration mode: Basic
  - Prefix delegation size: 56
  - Request Prefix Only: Yes
  - Send prefix hint: Yes

And, that's about it.

I just rebooted the firewall and it still isn't firing - starting dhcp6c and then a "configctl interface newip wan" brought up the V6 connectivity.

I have a very similar issue.

Restored my configuration from scratch, and now I cannot get dhcp6c to start automatically in any way.

If I run it by hand from the CLI, I have no problem pulling an IPv6 address.

Code Select Expand

/usr/local/sbin/dhcp6c -D -n -c /var/etc/dhcp6c.conf
/usr/local/sbin/configctl interface reconfigure wan

works fine, brings up the IPv6 addresses, delegates to my various VLANs and I'm off to the races.

Excited to see what changes are coming in 26.1 - for now I'll roll with the manual method rather than try to debug further ... no sense with major dhcp6c changes on tap.

Counter-intuitive since the console IS a USB port, but happy with the win. :)

How do you come to that conclusion? Are mixing up UART with USB? Or because the connector is USB? If the second, there are quite a few USB (Mini, Micro, C) and even a RJ45 (Cisco-style) serial connector. They are only the physical connector, probalby because they take up a lot less space then the original serial connector.

Simply, because what comes out of the box isn't RS-232.  Not the physical connector nor the protocol.  It's USB - RS-232 rides as a service, if you will, on top of the USB connection, but it's still USB.   Now, to clarify - as Patrick explained above, there's a Prolific USB-to-serial adapter on the board.

As I said, it's somewhat counterintuitive because what the physical hardware presents as USB, but the Prolific chip is somewhat abstracted away from the OS and its settings.  It's even more counterintuitive because it's smooth sailing from power on until runlevel 3 is complete - at which time it stops working.   

Honestly I was overthinking it - the OS just sees dumb RS232 and doesn't care about the prolific chip.

If you have the funding, I can't say enough great things about the Deciso hardware.  It's rock solid reliable, and supports OPNsense development.

I have the rack mount version of the DEC750 (I have the DEC2752) --> it's been nothing but a workhorse.  Only issues I've ever had have been my own misconfigurations!

I think this is wrong, remove that checkbox:

USB-based serial: "Use USB-based serial ports" - Yes

You're the best!!  That took care of it.  Working like a champ now.  Counter-intuitive since the console IS a USB port, but happy with the win. :)

So next up ... any performance tuning suggestions for the 10gb ax0/ax1 ports?  I made some tuning adjustments in /boot/loader.conf.local, but iperf3 throughput to another network node on the same LAN switch (US-XG-16) still tops out around 4gb/sec or so.

(I can move to a new thread if that's more appropriate. Thanks!)

Code Select Expand

kern.ipc.maxsockbuf=16777216
machdep.hyperthreading_intr_allowed=1
net.inet.rss.bits=3
net.inet.rss.enabled=1
net.inet.tcp.recvbuf_max=4194304
net.inet.tcp.sendbuf_inc=65536
net.inet.tcp.sendbuf_max=4194304
net.inet.tcp.soreceive_stream=1
net.isr.bindthreads=1
net.isr.defaultqlimit=2048
net.isr.dispatch=deferred
net.isr.maxthreads=-1

Hi all - I'm sure I'm missing a very simple console setting, but I just did a reload, and now I'm having serial console trouble.

Step 1) Install 25.7 via amd64/vga image
Step 2) Install default dec2752 settings from https://docs.opnsense.org/hardware/defaults.html
Step 3) Patch up to 25.7.10
Step 4) Restore my prior configuration (minus tunables - that is what I'm trying to get "clean" ...)

What is occurring:

Console works fine from BIOS to boot loader to console output.  But once boot finishes and I should be getting the login details, it stops providing output or accepting input right here:

Code Select Expand

>>> Invoking start script 'openvpn'
>>> Invoking start script 'sysctl'
Service `sysctl' has been restarted.
>>> Invoking start script 'beep'
Root file system: zroot/ROOT/default
Tue Jan 13 15:21:37 EST 2026

*** dmurphy-gw.home: OPNsense 25.7.10 (amd64) ***

 DMZ (vlan0.77)  -> v4: 10.77.0.1/24
 FIOS (igc0)     -> v4/DHCP4: 1.2.3.4/24
                    v6/DHCP6: fe80::ffff:aaaa:bbbb:cccc%igc0/64
 GUEST (vlan0.99) -> v4: 172.16.100.1/24
 LAN (ax0)       -> v4: 172.16.0.1/22
 Tailscale (tailscale0) ->
 WINTENDO (vlan0.91) -> v4: 172.16.91.1/24

 HTTPS: SHA256 83 AA EC BB 3D CC DD 0C EE 27 FF 0D AA 7A BB 6F
               CC DD EE FF AA BB BCC1 EF E0 60 05 0A AA BB CC DD
 SSH:   SHA256 PfdajklfdljkfgakvjczkzckHadfjkfdajfasjdcxxQ (ECDSA)
 SSH:   SHA256 PfdajklfdljkfgakvjczkzckHadfjkfdajfasjdcxxQ (ED25519)
 SSH:   SHA256 PfdajklfdljkfgakvjczkzckHadfjkfdajfasjdcxxQ (RSA)

Now if I do something that kicks out a kernel message (i.e. reboot) - I WILL see that output here.

So what setting am I missing?  In System -> Settings -> Administration, the Console settings are as such:

Code Select Expand

Console driver: "Use the virtual terminal driver (vt)" - Yes
Primary Console: Serial Console
Secondary Console: None
Serial Speed: 115200
USB-based serial: "Use USB-based serial ports" - Yes
Console menu: Password protect the console menu

EDIT: Forgot to mention, I did make sure "UART 0 Legacy" is disabled in the BIOS.

Code Select Expand

Setup Utility –> AMD CBS –> FCH Common Options –> UART Configuration Options –> UART 0 Legacy Options

> Just following up that I still see a memory leak in dnsmasq even after a reboot and an update to 25.7.10.

I don't think it's surprising given the fact that the binary did not change.

Exactly the expected behavior.  Was curious if the reboot and any of the netmap changes might make any difference, but appears not.

We'll see what happens when dnsmasq $version++ hits.  If it continues to drip memory, I'll spin up a dev machine, replicate the config and get dtrace running against it.

Again, not a big deal as recycling the process occasionally solves the practical issue, but now I want to know what I'm doing wrong to trip it up. :-)

Happy new year!!

[21656 0x1259f7e00000 0x125a00500000 rw- 31625 31625 1 0 ----- sw 21656 0x125a00600000 0x125a0a200000 rw- 29677 29677 1 0 ----- sw]

Just following up that I still see a memory leak in dnsmasq even after a reboot and an update to 25.7.10.

The cronjob which periodically restarts the process is keeping it from being an issue, but I still am trying to track down the leak.

Unfortunately it appears our base FreeBSD doesn't have proper dtrace support; it's mostly broken.

I also tried digging in with gdb but hit a deadend there too; can't really dig into jemalloc that way.

Anyway, looking forward to trying dnsmasq $version++ where we know there are memory leak fixes.  No urgency since the crontab process restart is doing its thing -- seems to be a slow leak.

For fun, here's a procstat -v.  You can see two memory regions that continue to grow.
[root@dmurphy-gw /usr/local/sbin]# procstat -v 21656
  PID              START                END PRT  RES PRES REF SHD FLAG  TP PATH
21656           0x200000           0x216000 r--   22  102   4   1 CN--- vn /usr/local/sbin/dnsmasq
21656           0x216000           0x264000 r-x   78  102   4   1 CN--- vn /usr/local/sbin/dnsmasq
21656           0x264000           0x265000 r--    1  102   4   1 CN--- vn /usr/local/sbin/dnsmasq
21656           0x265000           0x266000 r--    1    1   1   0 CN--- sw
21656           0x266000           0x268000 rw-    2    0   1   0 C---- vn /usr/local/sbin/dnsmasq
21656           0x268000           0x269000 rw-    1    1   1   0 C---- sw
21656        0x800e5b000        0x820e3b000 ---    0    0   0   0 ----- gd
21656        0x820e3b000        0x820e5b000 rw-    5    5   1   0 C--D- sw
21656        0x8219d8000        0x8219d9000 r-x    1    1  99   0 ----- ph
21656        0x8229c4000        0x8229ea000 r--   31   60  20  10 CN--- vn /usr/local/lib/libnettle.so.8.11
21656        0x8229ea000        0x822a16000 r-x   28   60  20  10 CN--- vn /usr/local/lib/libnettle.so.8.11
21656        0x822a16000        0x822a19000 r--    3    0   1   0 CN--- vn /usr/local/lib/libnettle.so.8.11
21656        0x822a19000        0x822a1a000 rw-    1    0   1   0 CN--- vn /usr/local/lib/libnettle.so.8.11
21656        0x823729000        0x82375b000 r--   17   39   4   2 CN--- vn /usr/local/lib/libhogweed.so.6.11
21656        0x82375b000        0x823771000 r-x   22   39   4   2 CN--- vn /usr/local/lib/libhogweed.so.6.11
21656        0x823771000        0x823772000 r--    1    0   1   0 CN--- vn /usr/local/lib/libhogweed.so.6.11
21656        0x823772000        0x823774000 rw-    2    0   1   0 CN--- vn /usr/local/lib/libhogweed.so.6.11
21656        0x8245aa000        0x8245cc000 r--   24   66   4   2 CN--- vn /usr/local/lib/libgmp.so.10.5.0
21656        0x8245cc000        0x824626000 r-x   42   66   4   2 CN--- vn /usr/local/lib/libgmp.so.10.5.0
21656        0x824626000        0x824627000 r--    1    0   1   0 CN--- vn /usr/local/lib/libgmp.so.10.5.0
21656        0x824627000        0x824629000 rw-    2    0   1   0 CN--- vn /usr/local/lib/libgmp.so.10.5.0
21656        0x824ede000        0x824f5d000 r--  121  451 308 114 CN--- vn /lib/libc.so.7
21656        0x824f5d000        0x825099000 r-x  316  451 308 114 CN--- vn /lib/libc.so.7
21656        0x825099000        0x8250a2000 r--    9    0   1   0 CN--- vn /lib/libc.so.7
21656        0x8250a2000        0x8250a9000 rw-    7    0   1   0 C---- vn /lib/libc.so.7
21656        0x8250a9000        0x8251ca000 rw-   19   19   1   0 C---- sw
21656     0x1259f7200000     0x1259f7221000 rw-   28   28   1   0 C---- sw
21656     0x1259f7400000     0x1259f7e00000 rw-  840  840   1   0 C---- sw
21656     0x1259f7e00000     0x125a00500000 rw- 31625 31625   1   0 ----- sw
21656     0x125a00600000     0x125a0a200000 rw- 29677 29677   1   0 ----- sw
21656     0x19660f171000     0x19660f177000 r--    6   30 251  57 CN--- vn /libexec/ld-elf.so.1
21656     0x19660f177000     0x19660f18e000 r-x   23   30 251  57 CN--- vn /libexec/ld-elf.so.1
21656     0x19660f18e000     0x19660f18f000 r--    1    0   1   0 CN--- vn /libexec/ld-elf.so.1
21656     0x19660f18f000     0x19660f190000 r--    1    1   1   0 CN--- sw
21656     0x19660f190000     0x19660f192000 rw-    2    2   1   0 C---- sw
21656     0x7fffffffe000     0x7ffffffff000 ---    0    0   0   0 ----- gd

Some extra data points on my current system

Thank you!  Here's my dnsmasq config; I removed the static reservations since they are repetitive and I didn't feel like masking all of the MAC addresses ... that's just pure laziness on my part.

Nothing crazy in here I don't think!

EDIT: Oh, FYI, the hardware is a DEC2752, vanilla standard ...  the internal interfaces are an 802.3ad active-active LAGG across ax0/ax1;  WAN is on igc0.

Code Select Expand

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
#

rebind-localhost-ok
stop-dns-rebind

port=53053

# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.
interface=lagg0_vlan77,lagg0_vlan99,lagg0,lagg0_vlan91



dhcp-fqdn
domain=home
# This tells dnsmasq that a domain is local and it may answer queries from /etc/hosts
# or DHCP but should never forward queries on that domain to any upstream servers.
local=/home/
local=/dmz/
local=/winhome/
local=/guest/




# On systems which support it, dnsmasq binds the wildcard address,
# even when it is listening on only some interfaces. It then discards
# requests that it shouldn't reply to. This has the advantage of
# working even when interfaces come and go and change address. If you
# want dnsmasq to really bind only the interfaces it is listening on,
# uncomment this option. About the only time you may need this is when
# running another nameserver on the same machine.
bind-interfaces




# Never forward addresses in the non-routed address spaces.
bogus-priv

server=/plex.direct/8.8.8.8
rebind-domain-ok=/plex.direct/

# By  default,  dnsmasq  will  send queries to any of the upstream
# servers it knows about and tries to favour servers to are  known
# to  be  up.  Uncommenting this forces dnsmasq to try each query
# with  each  server  strictly  in  the  order  they   appear   in
# /etc/resolv.conf
strict-order

# Never forward to servers in /etc/resolv.conf
no-resolv






# host entries flushed via dnsmasq_watcher.py [isc] and a dump of the static reservations
addn-hosts=/var/etc/dnsmasq-hosts
addn-hosts=/var/etc/dnsmasq-leases

dns-forward-max=5000
cache-size=10000
local-ttl=1

conf-dir=/usr/local/etc/dnsmasq.conf.d,*.conf

dhcp-range=tag:lagg0_vlan77,192.168.77.50,192.168.77.200,255.255.255.0,86400

domain=dmz,lagg0_vlan77
dhcp-range=tag:lagg0_vlan91,192.168.91.20,192.168.91.50,255.255.255.0,86400

domain=winhome,lagg0_vlan91
dhcp-range=tag:lagg0_vlan99,192.168.99.100,192.168.99.190,255.255.255.0,86400

domain=guest,lagg0_vlan99
dhcp-range=tag:lagg0,192.168.0.100,192.168.0.245,255.255.252.0,86400

domain=home,lagg0
dhcp-range=tag:lagg0,192.168.1.100,192.168.1.250,255.255.252.0,86400

domain=home,lagg0
dhcp-range=tag:lagg0,::,constructor:lagg0,ra-names,ra-stateless,64,86400

domain=home,lagg0
ra-param=lagg0,60,1200

dhcp-range=tag:lagg0_vlan77,::,constructor:lagg0_vlan77,ra-stateless,64,86400

domain=dmz,lagg0_vlan77
ra-param=lagg0_vlan77,60,1200

dhcp-range=tag:lagg0_vlan91,::,constructor:lagg0_vlan91,ra-names,ra-stateless,64,86400

domain=winhome,lagg0_vlan91
ra-param=lagg0_vlan91,60,1200

dhcp-range=tag:lagg0_vlan99,::,constructor:lagg0_vlan99,ra-stateless,64,86400

domain=guest,lagg0_vlan99
ra-param=lagg0_vlan99,60,1200


===== 8< 24 static reservations, all in the same format ... >8 =====
dhcp-host=08:00:20:00:00:00,192.168.0.3,sun-microsystems-forver
===== 8< 24 static reservations, all in the same format ... >8 =====

dhcp-option-force=tag:lagg0_vlan99,3,192.168.99.1
dhcp-option-force=tag:lagg0_vlan99,6,192.168.99.1
dhcp-option-force=tag:lagg0_vlan91,3,192.168.91.1
dhcp-option-force=tag:lagg0_vlan91,6,208.67.222.222,208.67.220.200
dhcp-option-force=tag:lagg0,1,255.255.252.0
dhcp-option-force=tag:lagg0,6,192.168.0.1
dhcp-option-force=tag:lagg0,3,192.168.0.1

# default dns mapped to this server (0.0.0.0)
dhcp-option=6,0.0.0.0


no-ident

Looks like your dnsmasq has a large memory footprint as well - keep an eye on it and see if it continues to grow.

I saw the same post about the dnsmasq 2.92RC3 but didn't have time last night to dig into the patch; seems it's related to parsing some static host files which "shouldn't" be the issue here, but who knows!  Worth checking out.

Thanks so much for digging into this ... thankfully the hourly restart is getting me through but it's certainly not ideal.

Good morning!  Until I can figure this out I setup a cron job to restart the dnsmasq process hourly so the network doesn't fold in on itself. :-)

I've got somewhere around 120 leases or so; it's not extraordinary by any means.

As soon as I'm back at my desk, I'll post my dnsmasq.conf.  Nothing extraordinary or terribly unusual.  I do have DNS listening on port 5353, as I'm using Unbound as the primary DNS.  (Unbound forwards my local zones to dnsmasq) - but very common config.

The restarted process has been running for 12 minutes .. memory size has ballooned to 98MB already (67MB resident) ...

Yikes.

Don't see any errors in the dnsmasq log - just the usual DHCPREQUEST/DHCPACK/RTR-SOLICIT/RTR-ADVERT etc.