RM520N-GL ipv6 connection failed

I am experiencing issues with RM520N-GL losing ipv6 connectivity.

RM520NGLAAR01A07M4G_01.201.01.201

I found a firmware changelog saying:

Solved the problem that the module probabilistically did not forward IPV6 NS packets to LAN device in bridge mode.

Is this applicable to my module and would it fix this issue? If yes, could someone send latest version?

That also implies that device might have a bridge mode which I haven’t found, does that actually refer to IPPT?

Current configuration:

AT+CGDCONT=1,"IPV4V6","internet"
AT+QMBNCFG="AutoSel",0

AT+QCFG="data_interface",1,0
AT+QCFG="pcie/mode",1

AT+QETH="eth_driver","r8125",1
AT+QETH="ipptmac",XX:XX:XX:XX:XX:XX

AT+QMAP="MPDN_rule",0,1,0,1,1,"XX:XX:XX:XX:XX:XX"
AT+QMAP="IPPT_NAT",0
AT+QMAP="DHCPV4DNS","disable"

AT+QCFG="usbcfg",0x2C7C,0x0801,0,0,1,0,0,0,0

Dear @kmrv
Which document did you see the firmware change log?
Did you try to configure ipv6 only via AT+CGDCONT? Did Ipv4 work fine?
For the latest firmware, you can contact with your provider firstly.

Dear @silvia

Quectel_RM520N-GL-AA_Firmware_Release_Notes_V0108_01.200.01.200.pdf page 7, module now running this has no issues so far.

@silvia

There seems to be an issue with forwarding router advertisements too, device behind RM520N-GL loses default route after a RA router lifetime times out, only first RA after establishing connection comes through.

Dear @kmrv
Please test the latest firmware.

@silvia

The link you sent seems to contain the same firmware that has been running on the module for over a week. sha1sums on the zip-files match and md5.txts match.

Dear @kmrv
Sorry, I missed your last information.
You module running well with RM520NGLAAR01A08M4G_01.200.01.200, right?

Dear @silvia

With firmware version RM520NGLAAR01A08M4G_01.200.01.200 I am experiencing default route loss after a timeout of router lifetime in a bit over 18 hours in my case. Router Advertisement below is received after a Router Solicitation message is sent, no periodic Router Announcements are received.

tcpdump:

11:13:24.663957 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104) fe80::xxxx:xxxx:xxxx:xxxx > fe80::yyyy:yyyy:yyyy:yyyy: [icmp6 sum ok] ICMP6, router advertisement, length 104
	hop limit 255, Flags [other stateful], pref medium, router lifetime 65535s, reachable time 0ms, retrans timer 0ms
	  source link-address option (1), length 8 (1): xx:xx:xx:xx:xx:xx
	  mtu option (5), length 8 (1):  1500
	  prefix info option (3), length 32 (4): name.fq.dn/64, Flags [onlink, auto], valid time infinity, pref. time infinity
	  rdnss option (25), length 40 (5):  lifetime 4294967295s, addr: dns1.fq.dn addr: dns2.fq.dn
Router Advertisement (Type 134)
    Routers advertise their presence together with various link and Internet parameters
    either periodically, or in response to a Router Solicitation message.

Dear @kmrv
Actually, I didn’t understand your problem now.
Could you try to configure router lifetime to longer?

Dear @silvia

Those Router Advertisements come from a router outside of our control, they are internet service providers devices.

EC25-E in IPPT mode had to pass thru those periodic Router Advertisements (I haven’t tried to dump that traffic on those) to keep default route information up to date, nothing has changed in the arrangement except replacement of the module and communication bus from USB to Ethernet.

Dear @kmrv
Actually, LTE and 5G are different, I am not sure if they can use the same solution.

Dear @silvia

I took a closer look into the modules firmware and found out that there were filter rules to DROP router solicitation and advertisements in place.

/ # ebtables -L --Ln
Bridge table: filter

Bridge chain: INPUT, entries: 2, policy: ACCEPT
1. -p IPv6 -s xx:xx:xx:xx:xx:xx --logical-in bridge0 -j ACCEPT 
2. -p IPv6 --logical-in bridge0 --ip6-proto ipv6-icmp --ip6-icmp-type router-solicitation -j DROP 

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 2, policy: ACCEPT
1. -p IPv6 -d xx:xx:xx:xx:xx:xx --logical-out bridge0 -j ACCEPT 
2. -p IPv6 --logical-out bridge0 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP 

I deleted those with

/ # ebtables -D INPUT 2
/ # ebtables -D OUTPUT 2

Result looks like

/ # ebtables -L --Ln
Bridge table: filter

Bridge chain: INPUT, entries: 1, policy: ACCEPT
1. -p IPv6 -s xx:xx:xx:xx:xx:xx --logical-in bridge0 -j ACCEPT 

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 1, policy: ACCEPT
1. -p IPv6 -d xx:xx:xx:xx:xx:xx --logical-out bridge0 -j ACCEPT 

I don’t know if first rule actually does anything, there is no DROP policy or rule in place.

I still havent received any router advertisements from internet service provider other than when dhcpv6 client is doing its requests.

Ok, that rule was meant to drop router solicitations and advertisements that didn’t match previous rule.

That is not what is causing my issue.

I have now had tcpdump -vvvv -tttt -i rmnet_data0 icmp6 and '(ip6[40] = 133 || ip6[40] = 134)' running on the module, internet service provider routers send advertisements every 6 hours but they don’t go through to next device.

Dear @kmrv
The question is that default route loss after a timeout of router lifetime in a bit over 18 hours with RM520NGLAAR01A08M4G_01.200.01.200 , right?

Dear @silvia

Yes, thats the issue. Those “refresh” advertisements from rmnet_data0 don’t go through.

First post shows the configuration of the module, target is to have as close as possible a data link layer bridge between LTE/5G and Ethernet using modules pcie bus connected to RTL8125 Ethernet controller which is connected to a device doing the actual routing.

On a sidenote, IPv4 arrangement of the module works ok for the this target, it would be optimal if whole IPv6 address prefix which internet service provider give would be passed through and module wouldn’t have external IPv6 address of its own either, but I guess current arrangement is something we can live with.

I would also like to suggest that if module has to have an external IPv6 address of its own, it would be good to keep iptables rules in sync for both protocols, IPv4 and IPv6.

Dear @kmrv
Thanks for your informatio, I will check internally.