RM551E-GL IPv6 prefix delegation & depreciation

When using the RM551-E-GL in router mode (IPv4 NAT in the 192.168.224.0/22 range and IPv6 delegation), in conjunction with MacOS, I have the issue that once in a while, IPv6 connectivity breaks due to old IPv6 prefixes not being depreciated properly.

The root cause for the IPv6 prefix “collection” piling up is that the provider still uses the silly 24-hourly disconnect.

Now it’s difficult to say whether this is an issue with the RM551E-GL modem/router or the OS, but one cause for MacOS not throwing away the old prefixes can be the router not marking the former prefixes with lifetimes of zero as described here.

Hence the question: does Quectel factor changing /64 prefixes in and sends the according RA messages?

Dear @little-endian
Our engineer had checked this and test on EVB, here is the feedback as below.
i have verified on EVB, when v6 prefix update, the old one will be depreciated by lifetime set as 0.
if it did not work well on your host, please check your OS or router setting.

@silvia: Brilliant, that is the kind of support one wishes for. Thanks a lot for such a elaborate follow-up!

Guess I have to do further testing then. Currently, the Quectel-Modem is in a “Dual-Q 5G2PHY” board, hooked up via Ethernet to a pair of Cudy M3000 in bridge mode however, so they shouldn’t have anything to do with the router advertisements and mostly MacBooks.

Despite having the AT-command guide for the RM551 modem, could you tell me

a) with what command I can check the current connection time to the provider APN? Reason is that the ISP disconnects the connection every 23h59m03s, so almost 24h. Since there can always be a hickup in between, without any output of the running connection, I don’t easily know when the next reconnection is to be expected

b) how I can manually reconnect the APN-connection to trigger a new IPv6 prefix. If I restart the modem, the time span is too long as the end devices then would lose the connection entirely and retrigger the DHCP-process which doesn’t properly simulate the way shorter ISP reconnects

Thanks!

Dear @little-endian
For a)We didn’t have the AT command, you can monitor on your MCU side.
For b)You can use the AT commands to try:
at+qmap=“mpdn_rule”,0
at+qmap=“mpdn_rule”,0,1,0,0,1