LTE sim connection problem on APU2 board

Dear all,
I am writing as I am trying to configure a Sierra Wireless MC7455 mPCIe module to work with OpenWrt 21.02.1 on a PC Engines x86_64 APU2 board (equipped with two mPCIe slot and one SIM slot, connected to one of the mPCIe slots).
I installed uqmi 2022-04-22-0.5 and followed both the official documentation: https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle
and this guide:
https://teklager.se/en/knowledge-base/openwrt-4g-wwan-configuration/

However, no matter if I specify an APN, or leave it empty, I always end up with the following error:
Error: Unknown error (IPV4_APN_ERROR)

My /etc/config/network file contains the following section for LTE:

config interface 'LTE'
	option proto 'qmi'
	option ifname 'wwan0'
	option auth 'none'
	option dhcpv6 '1'
	option metric '10'
	option pdptype 'ipv4v6'
	option device '/dev/cdc-wdm0'
	option apn 'wp.tim.it'
	option default_profile '1'
	option dualstack_profile '2'

The command logread instead reports the following errors:

Tue May  2 13:43:23 2023 daemon.notice netifd: Interface 'LTE' is setting up now
Tue May  2 13:43:24 2023 daemon.notice netifd: LTE (7668): PINcode disabled
Tue May  2 13:43:24 2023 daemon.notice netifd: LTE (7668): Data format set to raw-ip
Tue May  2 13:43:24 2023 daemon.notice netifd: LTE (7668): Default profile number: 1
Tue May  2 13:43:25 2023 daemon.notice netifd: LTE (7668): Initiate airplane mode
Tue May  2 13:43:26 2023 daemon.notice netifd: LTE (7668): Change default profile
Tue May  2 13:43:26 2023 daemon.notice netifd: LTE (7668):  apn:  to wap.tim.it
Tue May  2 13:43:26 2023 daemon.notice netifd: LTE (7668): Configure profile for dual-stack
Tue May  2 13:43:27 2023 daemon.notice netifd: LTE (7668): Dual-stack profile number: 2
Tue May  2 13:43:27 2023 daemon.notice netifd: LTE (7668): Airplane mode off
Tue May  2 13:43:28 2023 daemon.notice netifd: LTE (7668):  registered on 22201
Tue May  2 13:43:31 2023 daemon.notice netifd: LTE (7668): Registered to TIM on LTE
Tue May  2 13:43:32 2023 daemon.notice netifd: LTE (7668): Unable to connect with ipv4, check APN settnings
Tue May  2 13:43:32 2023 daemon.notice netifd: LTE (7807): Stopping network LTE
Tue May  2 13:43:32 2023 daemon.notice netifd: LTE (7807): Command failed: Permission denied
Tue May  2 13:43:32 2023 daemon.notice netifd: Interface 'LTE' is now down

Do you have any idea of where the issue could be?
There could be a configuration error somewhere?

Thanks a lot in advance.

1 Like

Are you sure about your APN settings? According to this it's either wap.tim.it (not wp.tim.it) or ibox.tim.it.

Did you try different IP pdptypes? Where did you get the dualstack_profile information from?

EDIT: According to the TIM site, it's IPv4 only, not dualstack or IPv6. I just had a look at the Huawei configuration guide at https://www.tim.it/assistenza/supporto-smartphone/guide/huawei, you can see it in a screenshot that the IP type is set to IPv4).

2 Likes

Hello, thank you for your answer!
You're right, it was wap.tim.it, I accidentaly cancelled the 'a' while posting but it was setted correctly on the /etc/config/network file.
I tried following your suggestion and change pdptype to ipv4 only but it keeps giving the same error IPV4_APN_ERROR with both apn wap.tim.it and ibox.tim.it.
For what concerns the pdptype I tried all the available options (IPv4, IPv6, IPv4v6) but it always shows the IPV4_APN_ERROR error.
Looking at the logread lines, I noticed that the only difference I got between the IPv version is that with IPv6 the procedure get stuck while serching on 22201.
The dualstack_profile information was automatically generated while setting the LTE interface through the LuCI web interface.

Could you try with modem manager?
It goes further to get specific devices working.
You won't need to worry about protocols (usually). Well known defaults for specific modems are already baked in.

You could use mmcli to test any modem issues.

https://www.freedesktop.org/software/ModemManager/man/1.0.0/mmcli.8.html

1 Like

That would have been my next suggestion too. I couldn't get a modem to work with uqmi either that worked immediately with ModemManager.

1 Like

Hi
You could try my latest version, 2022-11-29-0.10. It is just uploaded.

Thank you all very much for your reply!
I have now installed your latest version and I don't have the IPV4_ APN_ERROR anymore.
However the connection is not stable and there is a disconnection about every 60 seconds.

This is what I can see from the logread:

Mon May  8 14:47:24 2023 daemon.notice netifd: Interface 'LTE' is now up
Mon May  8 14:47:24 2023 daemon.notice netifd: Network device 'wwan0' link is up
Mon May  8 14:47:37 2023 daemon.err odhcpd[3439]: Failed to send to ff02::1%lan@eth1 (Permission denied)
Mon May  8 14:47:53 2023 daemon.err odhcpd[3439]: Failed to send to ff02::1%lan@eth1 (Permission denied)
Mon May  8 14:47:55 2023 user.notice uqmi_d: Modem disconnected
Mon May  8 14:47:55 2023 daemon.notice netifd: Interface 'LTE' has lost the connection
Mon May  8 14:47:55 2023 daemon.notice netifd: Network device 'wwan0' link is down
Mon May  8 14:47:55 2023 user.notice uqmi_d: IPv4 re-connected
Mon May  8 14:47:55 2023 daemon.notice netifd: Interface 'LTE' is now up
Mon May  8 14:47:55 2023 daemon.notice netifd: Network device 'wwan0' link is up

From the graphic interface I can see that there are only transmitted packets and not received packets:

By using the command uqmi -d /dev/cdc-wdm0 --get-data-status I can see that the device is disconnected.

I have also tried forcing the connection on IPv4 only instead of IPv4v6, but it keeps giving the same kind of issue.

Do you have any idea of where the problem could be?

Thanks a lot in advance.

It seems to be an issue with the daemon. Can you print uci show network ?

You can de-activate the daemon with:

uci set network.LTE.daemon=false
uci commit network

The uci show network prints the following:

network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fd1f:f394:1093::/48'
network.LTE=interface
network.LTE.proto='qmi'
network.LTE.device='/dev/cdc-wdm0'
network.LTE.auth='none'
network.LTE.apn='wap.tim.it'
network.LTE.pdptype='ipv4'
network.LTE.default_profile='1'
network.lan=interface
network.lan.device='eth1'
network.lan.proto='static'
network.lan.ipaddr='10.0.2.118'
network.lan.netmask='255.255.255.0'
network.lan1=interface
network.lan1.device='eth2'
network.lan1.proto='static'
network.lan1.ipaddr='10.0.1.118'
network.lan1.netmask='255.255.255.0'
network.wan=interface
network.wan.device='eth0'
network.wan.proto='dhcp'
network.wan6=interface
network.wan6.device='eth0'
network.wan6.proto='dhcpv6'
network.docker=interface
network.docker.device='docker0'
network.docker.proto='none'
network.docker.auto='0'
network.@device[0]=device
network.@device[0].type='bridge'
network.@device[0].name='docker0'

I tried de-activating the daemon with the commands you suggested but the connection is still sending only packets without receiving them.
This is the uci show network after de-activating the daemon:

network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fd1f:f394:1093::/48'
network.LTE=interface
network.LTE.proto='qmi'
network.LTE.device='/dev/cdc-wdm0'
network.LTE.auth='none'
network.LTE.apn='wap.tim.it'
network.LTE.pdptype='ipv4'
network.LTE.default_profile='1'
network.LTE.daemon='false'
network.lan=interface
network.lan.device='eth1'
network.lan.proto='static'
network.lan.ipaddr='10.0.2.118'
network.lan.netmask='255.255.255.0'
network.lan1=interface
network.lan1.device='eth2'
network.lan1.proto='static'
network.lan1.ipaddr='10.0.1.118'
network.lan1.netmask='255.255.255.0'
network.wan=interface
network.wan.device='eth0'
network.wan.proto='dhcp'
network.wan6=interface
network.wan6.device='eth0'
network.wan6.proto='dhcpv6'
network.docker=interface
network.docker.device='docker0'
network.docker.proto='none'
network.docker.auto='0'
network.@device[0]=device
network.@device[0].type='bridge'
network.@device[0].name='docker0'

This solved the issue about the re-connection every 60 seconds since now the connection has been up for 5 minutes straight!

What do you think is the problem with the reception of packets?

Thank you very much!

I just saw from the ifconfig that the wwan0 has in the HW address only zeros while all the other interfaces have a real hexadecimal address:

docker0   Link encap:Ethernet  HWaddr 02:42:DC:34:C5:1C  
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:0D:B9:5F:4A:78  
          inet addr:10.0.1.23  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:b9ff:fe5f:4a78/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1727 errors:0 dropped:1359 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:140136 (136.8 KiB)  TX bytes:5794 (5.6 KiB)
          Memory:fe500000-fe51ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:5F:4A:79  
          inet addr:10.0.2.118  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe600000-fe61ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:5F:4A:7A  
          inet addr:10.0.1.118  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:b9ff:fe5f:4a7a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10434 errors:0 dropped:1359 overruns:0 frame:0
          TX packets:17226 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1021970 (998.0 KiB)  TX bytes:6762195 (6.4 MiB)
          Memory:fe700000-fe71ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2433 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2433 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:173424 (169.3 KiB)  TX bytes:173424 (169.3 KiB)

wlan0     Link encap:Ethernet  HWaddr 18:FD:74:45:C2:31  
          inet6 addr: fe80::1afd:74ff:fe45:c231/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:872 (872.0 B)

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::8446:34b9:3b8a:75d2/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:384 (384.0 B)

I thought this might be a useful clue to solve the problem, thank you again in advance!

Have you assign any firewall zone to you LTE interface?

Could you run:
uci show network | grep qmi | awk -F . '{print $2}'
ubus call network.interface.<use the result from previous command> status
uqmi -d /dev/cdc-wdm0 --set-client-id wds,<cid_4, from ubus command> --get-current-settings
uqmi -d /dev/cdc-wdm0 --set-client-id wds,<cid_6, from ubus command> --get-current-settings

Sure, thank you for your help!
By running uci show network | grep qmi | awk -F . '{print $2}' I get:

LTE

With ubus call network.interface.LTE status I get:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 10524,
	"l3_device": "wwan0",
	"proto": "qmi",
	"updated": [
		"routes"
	],
	"metric": 10,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "0.0.0.0",
			"mask": 0,
			"nexthop": "0.0.0.0",
			"source": "0.0.0.0/0"
		}
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"cid_4": "35",
		"pdh_4": "\"No effect\""
	}
}

With uqmi -d /dev/cdc-wdm0 --set-client-id wds,35 --get-current-settings I get:

"Out of call"

I couldn't run uqmi -d /dev/cdc-wdm0 --set-client-id wds,<cid_6, from ubus command> --get-current-settings because I didn't get a cid_6 from the ubus command.

For the firewall zone I don't think I have assigned any yet since I did not modified the /etc/config/firewall file.
In the /etc/config/firewall I have the following involving the config zone:

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        list network 'wwan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

Add your LTE interface to the same firewall zone as wan and wan6:
Go to Nerwork - Interfaces
Edit the LTE interface
In tab "Firewall Settings", add LTE to the same firewall zone as wan / wan6
Save
Save & Apply

Power reboot your router. When all are up, please, print:
logread -e LTE
ubus call network.interface.LTE status

Thank you very much! I have followed the procedure you described and rebooted the router.
By using logread -e LTE I get:

Wed May 10 07:03:49 2023 daemon.notice netifd: Interface 'LTE' is setting up now
Wed May 10 07:03:59 2023 daemon.notice netifd: LTE (4113): PINcode disabled
Wed May 10 07:03:59 2023 daemon.notice netifd: LTE (4113): Data format set to raw-ip
Wed May 10 07:04:00 2023 daemon.notice netifd: LTE (4113): Default profile: 1
Wed May 10 07:04:00 2023 daemon.notice netifd: LTE (4113):  registered on 22201
Wed May 10 07:04:01 2023 daemon.notice netifd: LTE (4113): Registered to TIM on LTE
Wed May 10 07:04:02 2023 daemon.notice netifd: LTE (4113): Connected with IPv4
Wed May 10 07:04:02 2023 daemon.notice netifd: LTE (4113): Setting up wwan0
Wed May 10 07:04:02 2023 daemon.notice netifd: Interface 'LTE' is now up
Wed May 10 07:04:02 2023 daemon.notice netifd: LTE (4113): Failed to parse message data
Wed May 10 07:04:02 2023 daemon.notice netifd: LTE (4113): WARNING: Variable 'ipv4' does not exist or is not an array/object
Wed May 10 07:04:02 2023 user.notice firewall: Reloading firewall due to ifup of LTE (wwan0)
Wed May 10 07:04:02 2023 user.notice firewall: Reloading firewall due to ifupdate of LTE (wwan0)

With ubus call network.interface.LTE status I get:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 134,
	"l3_device": "wwan0",
	"proto": "qmi",
	"updated": [
		"routes",
		"data"
	],
	"metric": 10,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "0.0.0.0",
			"mask": 0,
			"nexthop": "0.0.0.0",
			"source": "0.0.0.0/0"
		}
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"cid_4": "35",
		"pdh_4": "\"No effect\"",
		"zone": "wan"
	}
}

I looked at the ifconfig and there are only 4 transmitted packets and 0 received packets on the LTE interface.
What can I try to do next to fix this problem?
Thank you very much for your help!

I tried giving a poweroff on the APU and it looks like now it has applied the changes and is able to connect.
The output on the terminal with logread -e LTE
has changed to

Wed May 10 11:17:01 2023 daemon.notice netifd: Interface 'LTE' is setting up now
Wed May 10 11:17:11 2023 daemon.notice netifd: LTE (4140): PINcode disabled
Wed May 10 11:17:11 2023 daemon.notice netifd: LTE (4140): Data format set to raw-ip
Wed May 10 11:17:11 2023 daemon.notice netifd: LTE (4140): Default profile: 1
Wed May 10 11:17:12 2023 daemon.notice netifd: LTE (4140): Initiate airplane mode
Wed May 10 11:17:13 2023 daemon.notice netifd: LTE (4140): Change default profile
Wed May 10 11:17:13 2023 daemon.notice netifd: LTE (4140):  authentication: both to none
Wed May 10 11:17:14 2023 daemon.notice netifd: LTE (4140): Airplane mode off
Wed May 10 11:17:15 2023 daemon.notice netifd: LTE (4140):  registered on 22201
Wed May 10 11:17:18 2023 daemon.notice netifd: LTE (4140): Registered to TIM on LTE
Wed May 10 11:17:22 2023 daemon.notice netifd: LTE (4140): Unable to connect with ipv4, check APN settnings
Wed May 10 11:17:22 2023 daemon.notice netifd: LTE (6176): Stopping network LTE
Wed May 10 11:17:22 2023 daemon.notice netifd: LTE (6176): Command failed: Permission denied
Wed May 10 11:17:22 2023 daemon.notice netifd: Interface 'LTE' is now down
Wed May 10 11:18:08 2023 daemon.notice netifd: Interface 'LTE' is setting up now
Wed May 10 11:18:18 2023 daemon.notice netifd: LTE (6776): PINcode disabled
Wed May 10 11:18:19 2023 daemon.notice netifd: LTE (6776): Data format set to raw-ip
Wed May 10 11:18:19 2023 daemon.notice netifd: LTE (6776): Default profile: 1
Wed May 10 11:18:19 2023 daemon.notice netifd: LTE (6776): Initiate airplane mode
Wed May 10 11:18:21 2023 daemon.notice netifd: LTE (6776): Change default profile
Wed May 10 11:18:21 2023 daemon.notice netifd: LTE (6776):  authentication: both to none
Wed May 10 11:18:21 2023 daemon.notice netifd: LTE (6776): Airplane mode off
Wed May 10 11:18:22 2023 daemon.notice netifd: LTE (6776):  registered on 22201
Wed May 10 11:18:26 2023 daemon.notice netifd: LTE (6776): Registered to TIM on LTE
Wed May 10 11:18:34 2023 daemon.notice netifd: LTE (6776): Connected with IPv4
Wed May 10 11:18:34 2023 daemon.notice netifd: LTE (6776): Setting up wwan0
Wed May 10 11:18:34 2023 daemon.notice netifd: Interface 'LTE' is now up
Wed May 10 11:18:34 2023 user.notice firewall: Reloading firewall due to ifup of LTE (wwan0)
Wed May 10 11:18:34 2023 user.notice firewall: Reloading firewall due to ifupdate of LTE (wwan0)

while the output for ubus call network.interface.LTE status has changed in:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 86,
	"l3_device": "wwan0",
	"proto": "qmi",
	"updated": [
		"addresses",
		"routes",
		"data"
	],
	"metric": 10,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "10.80.113.159",
			"mask": 26
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "0.0.0.0",
			"mask": 0,
			"nexthop": "10.80.113.160",
			"source": "0.0.0.0/0"
		}
	],
	"dns-server": [
		"217.200.201.64",
		"217.200.201.65"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"cid_4": "36",
		"pdh_4": "62666752",
		"zone": "wan"
	}
}

Moreover I tried connecting by using 'ping 8.8.8.8' and it connects correctly to the internet through the lte interface. By the ping reqest I get packets both transmitted and received.

Thank you very much for your help!

After using correctly the TIM sim, following your suggestions, I tried using a vodafone sim. Unfortunately this time the connection didn't work and gave the same error as the TIM sim at the very start.

The error that I got is the following:

Wed May 10 10:55:22 2023 daemon.notice netifd: Interface 'LTE' is setting up now
Wed May 10 10:55:32 2023 daemon.notice netifd: LTE (4130): PINcode disabled
Wed May 10 10:55:32 2023 daemon.notice netifd: LTE (4130): Data format set to raw-ip
Wed May 10 10:55:33 2023 daemon.notice netifd: LTE (4130): Default profile: 1
Wed May 10 10:55:33 2023 daemon.notice netifd: LTE (4130): Initiate airplane mode
Wed May 10 10:55:34 2023 daemon.notice netifd: LTE (4130): Change default profile
Wed May 10 10:55:34 2023 daemon.notice netifd: LTE (4130):  apn:  to web.omnitel.it
Wed May 10 10:55:34 2023 daemon.notice netifd: LTE (4130):  authentication: both to none
Wed May 10 10:55:35 2023 daemon.notice netifd: LTE (4130): Airplane mode off
Wed May 10 10:55:36 2023 daemon.notice netifd: LTE (4130):  searching on 22210
Wed May 10 10:55:38 2023 daemon.notice netifd: LTE (4130):  searching on 22210
Wed May 10 10:55:41 2023 daemon.notice netifd: LTE (4130):  registered on 22210
Wed May 10 10:55:41 2023 daemon.notice netifd: LTE (4130): Registered to vodafone IT on LTE
Wed May 10 10:55:43 2023 daemon.notice netifd: LTE (4130): Unable to connect with ipv4, check APN settnings
Wed May 10 10:55:43 2023 daemon.notice netifd: LTE (6187): Stopping network LTE
Wed May 10 10:55:43 2023 daemon.notice netifd: LTE (6187): Command failed: Permission denied
Wed May 10 10:55:43 2023 daemon.notice netifd: Interface 'LTE' is now down

I tried to set the APN to both web.omnitel.it and mobile.vodafone.it for the Vodafone sim, but none of them was able to connect or keep the LTE interface up.

Do you have any suggestion on how to make both the sim work on the APU?

Thank you in advance!

Can you run uqmi -d /dev/cdc-wdm0 --get-current-settings when you have the Vodafone SIM in the APU2?

BTW, did you power reset your router after you change the SIM cards?