Hi
I create a dynamic DHCPv6 interface, but I have to add the DNSs manually.
The DNS addresses needs to be converted to HEX-format.
https://blog.siriling.com:1212/2023/04/12/5g-modem-fibocom-fm350-gl/#jiu-gu-jian-sheng-ji
here is tutorial about FM350-GL
Does anyone here had issues with mtk7xx driver and modemmanager crash/kernel panic?. After the crash openwrt restart then cannot access luci anymore. i had to power off than power on back. The issues liked this.
Hi. I've been experimenting with this module and this adapter
in the hopes of using them with OpenWRT on an Intel NUC that I have laying around. Initially, I got it working quite nicely over USB with the instructions on this forum. But while playing with it, I accidentally set the interface to PCIe only and now it's not reachable anymore.
Do you know if it would be possible to access the AT endpoint via the ethernet connection of the adapter above?
I also tried to boot the device in Preloader and other modes using mtkclient or mtk bootseq, but I'm not able to send AT commands that way either.
Unfortunately, among a lot of devices I have laying around the house, I don't have a single one with an M.2 B key connector with PCIe
Thank you for these. This has been helpful doing some troubleshooting on my own card here. I've also been working with this package here while working on all this: modemfeed/packages/net/fm350-modem at master · koshev-msk/modemfeed (github.com)
However I've run into an odd issue and not sure where to look at next. First run I had it on a plain old x86 laptop with the FM350-GL in an internal M.2 slot (Still in USB mode) with 23.05.3 installed. With the package from the modemfeed repo installed during that it seemed to work fine. It basically goes through the same manual steps discussed here in this thread. I've currently got it set up with a T-Mobile US SIM which necessitates an IPV4IPV6 config.
I've since tried moving this to a Pi 4 (with 23.05.3 again) with the card in an M.2>USB adapter also attached through a powered USB hub. I've had this particular setup working before and it currently works fine with some other LTE cards I'm also using.
However now I seem to have an issue that it is not pulling an IPV4 address. This is with both the package from modemfeed and the fib-fm350_gl package linked here. It seems like it can pull a v6 address fine. In fact with the fib-fm350_gl package it successfully connects but the primary interface (in Luci), assuming it's intended to be for v4, just shows the MAC and TX/RX bytes. The second interface shows just the v6 info. I can successfully ping out of the v6 side as well.
Here's an excerpt from the AT commands ran where the IP should show:
AT+CGPADDR=1
+CGPADDR: 1,"","0.0.0.0.0.0.0.0.172.57.56.247.79.57.199.27"
The config has stayed consistent in all attempts so far. IP type set to IPV4V6, apn set for fast.t-mobile.com, no auth or other settings.
I'm just curious if there's any suggestions where I can begin to troubleshoot this? I can get more detailed logs later this afternoon. I'm kinda wondering if it may be something on the carrier side but not sure there.
That is ac39:38f7:4f39:c71b
with leading zeroes omitted.
I guess it is a PDN IPv6 Interface ID (not address), that is used to obtain the actual IPv6 address. Providing just the Interface ID seems to be a feature of Fibocom.
The Link-Local address to use will be fe80::ac39:38f7:4f39:c71b
Make sure your firmware is up to date, there is always a hope that they will change something for better.
Thanks! I had avoided that for the time being since it seemed like the process was a bit sketchy. But I pored over the long thread over on the 4PDA forums for this card since it seemed like it had a lot of useful info including discussions on the firmware updates. Found the instructions on updating via USB and seemed to go well. The card I have looks to be the Dell variant (DW5931e) so grabbed the latest driver package from Dell (Release date March 2024) and used the firmware files from there.
For the fib-fm350_gl package mrhaav provided, it is even worse off and seems to be in a cycle of checking the CPIN command over and over:
AT+CPIN?
+CPIN: READY
OK
Switching over to the modemfeed repo FM350 package, it is in the same spot as before. Here's the log from minicom (Seems there's some missing characters here and there. Not sure if that's normal?) for the lines that just keep repeating:
AT+CMEE=2
OK
AT+CGDCAF=1,0,0,0
OK
OK
ONT=1
OK
AT+CGDCONT=1,"IPV4V6","fast.t-mobile.com"
OK
AT+CGPADDR=1
+CGEV: ME PDN ACT 1
OK
+CGPADDR: 1,"0.0.0.0.0.0.0.0.10.210.41.87.128.214.194.84",""
OK
AT+CGPADDR=1
+CGPADDR: 1,"0.0.0.0.0.0.0.0.10.210.41.87.128.214.194.84",""
OK
AT+GTDNS=1
+GTDNS: 1,"253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.9","253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.16"
OK
AT+CGACT=0,1
+CGEV: ME PDN DEACT 1
OK
Doing some additional troubleshooting on my own and toying with various commands:
The CPIN error mentioned it seems like maybe there's some kind of delay issue going on? Sending the commands it is using to run that check get empty results. This is literally the output I see:
root@OpenWrt:~# $(COMMAND='AT+CPIN?' gcom -d "/dev/ttyUSB8" -s /etc/gcom/getrun_at.gcom | grep CPIN: | awk -F ' ' '{print $2 $3}' | sed -e 's/[\r\n]//g')
root@OpenWrt:~# COMMAND='AT+CPIN?' gcom -d "/dev/ttyUSB8" -s /etc/gcom/getrun_at.gcom
Secondly when I go back and just manually enter the commands, it seems to pull a V4 address reliably:
AT+CGDCONT=1,"IPV4V6","fast.t-mobile.com"
OK
AT+CGACT=1,1
+CGEV: ME PDN ACT 1
OK
AT+CGPADDR=1
+CGPADDR: 1,"21.189.141.209","0.0.0.0.0.0.0.0.172.57.56.247.78.55.173.182"
OK
But when leaving the modemfeed FM350 package (which is the only one that seems to get the farthest between the two now) to its own automatic process, it just goes back to the cycle above with no V4 address. Kinda feels like a timing issue here as well but that's just a wild guess. Next thing to try may be putting a delay between commands in the script and see what happens.
Strange.
What do you have in the Syslog when you run my script?
Do you use it with luci-proto-atc
?
If you try an other AT-command, like AT+CGDCONT?
. Do you get any response?
I've mostly been using Luci addon for all this, but the interface in the network config file looks to be accurate:
config interface 'TM_5G'
option proto 'atc'
option device '/dev/ttyUSB8'
option apn 'fast.t-mobile.com'
option auth '0'
option pdp 'IPV4V6'
option atc_debug '2'
option metric '25'
Here's the syslog starting from a restart triggered from the web UI.
Tue Jun 11 18:29:31 2024 daemon.notice netifd: TM_5G (31367): TM_5G is disconnected
Tue Jun 11 18:29:31 2024 daemon.notice netifd: TM_5G (31367): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "TM_5G" } (Permission denied)
Tue Jun 11 18:29:31 2024 daemon.notice netifd: Interface 'TM_5G' is now down
Tue Jun 11 18:29:31 2024 daemon.notice netifd: Interface 'TM_5G' is setting up now
Tue Jun 11 18:29:33 2024 daemon.notice netifd: TM_5G (31374): Initiate modem with interface eth1
Tue Jun 11 18:29:58 2024 daemon.notice netifd: TM_5G (31374): sh: running: unknown operand
The command given still returns an empty response while I can clearly see the same READY response from minicom once it runs:
root@OpenWrt:~# COMMAND='AT+CPIN?' gcom -d "/dev/ttyUSB8" -s /etc/gcom/getrun_at.gcom
root@OpenWrt:~#
AT+CPIN?
+CPIN: READY
OK
Do you get any response if you run:
COMMAND='AT+CGDCONT?' gcom -d "/dev/ttyUSB8" -s /etc/gcom/getrun_at.gcom
?
I suppose you use port /dev/ttyUSB8
with picocom
aswell?
Identical situation with that command as well. Nothing from the command line but minicom/picocom show the appropriate response:
AT+CGDCONT?
+CGDCONT: 1,"IPV4V6","fast.t-mobile.com","",,,,,,,,,,
OK
minicom vs picocom don't seem to behave any different here. Also I did not try the different USB mode. Was on 41 but tried 40 just for the heck of it. No difference other than the port change.
Can you try:
COMMAND='AT+CMEE=2' gcom -d "/dev/ttyUSB8" -s /etc/gcom/run_at.gcom
?
A little bit different this time. Took it a bit before the timeout message appeared. Don't mind the port change. It's still on mode 40 after the last attempt.
root@OpenWrt:~# COMMAND='AT+CMEE=2' gcom -d "/dev/ttyUSB6" -s /etc/gcom/run_at.gcom
Timeout running AT-command; AT+CMEE=2
root@OpenWrt:~#
picocom/minicom output:
AT+CMEE=2
OK
Are you running picocom
at the same time?
Or any other application using the same port?
Got a chance to play around a bit more last night and seems like a self inflicted fault. I was keeping minicom/picocom open while trying all this for debugging purposes. But once I closed them out (I also made sure nothing else was accessing the ttyUSB port) the commands did provide responses and the syslog did show it made a successful connection. So my bad on that one . But it is back to no V4 address and I think no routable V6 address either. I need to recheck that.
I'm going to get those logs hopefully here in the next couple hours. I want to do some more testing. Right now this is with a T-Mobile US prepaid SIM. I also have a few other active SIM cards including a postpaid T-Mobile SIM and a Verizon (technically US Mobile) SIM. The latter is currently on an LTE card (Quectel EC25-AF) and successfully pulls both V6 and V4 addresses with working network connectivity. I want to try all those to potentially rule out any hardware/software issues.
So the Verizon/US Mobile SIM works great on the FM350. But it seems like both my Prepaid and Postpaid T-Mobile SIMs exhibit the same issue. They'll connect, but no V4 address. However they work fine in my EC25-AF LTE card. Here's logs I have:
T-Mobile Prepaid - FM350 5G
Wed Jun 12 12:13:33 2024 daemon.notice netifd: Interface 'TM_5G' is now down
Wed Jun 12 12:13:33 2024 daemon.notice netifd: Interface 'TM_5G' is setting up now
Wed Jun 12 12:13:34 2024 daemon.notice netifd: TM_5G (5556): Initiate modem with interface eth1
Wed Jun 12 12:13:37 2024 daemon.notice netifd: TM_5G (5556): SIMcard ready
Wed Jun 12 12:13:38 2024 daemon.notice netifd: TM_5G (5556): Configure modem
Wed Jun 12 12:13:51 2024 daemon.notice netifd: TM_5G (5556): Activate modem
Wed Jun 12 12:13:53 2024 daemon.notice netifd: TM_5G (5556): +CIREPI: 0,0
Wed Jun 12 12:13:53 2024 daemon.notice netifd: TM_5G (5556): +EONSNWNAME: 1, 0, "T-Mobile", 0, "T-Mobile"
Wed Jun 12 12:13:53 2024 daemon.notice netifd: TM_5G (5556): +CTZV: -16,1
Wed Jun 12 12:13:54 2024 daemon.notice netifd: TM_5G (5556): AT+COPS?
Wed Jun 12 12:13:54 2024 daemon.notice netifd: TM_5G (5556): +COPS:0,2,"310260",11
Wed Jun 12 12:13:54 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:54 2024 daemon.notice netifd: TM_5G (5556): AT+COPS=3,0
Wed Jun 12 12:13:54 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:55 2024 daemon.notice netifd: TM_5G (5556): AT+COPS?
Wed Jun 12 12:13:55 2024 daemon.notice netifd: TM_5G (5556): +COPS:0,0,"T-Mobile",11
Wed Jun 12 12:13:55 2024 daemon.notice netifd: TM_5G (5556): Registered to T-Mobile PLMN:310260 on 11
Wed Jun 12 12:13:55 2024 daemon.notice netifd: TM_5G (5556): Activate session
Wed Jun 12 12:13:55 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:56 2024 daemon.notice netifd: TM_5G (5556): AT+CGACT=1,1
Wed Jun 12 12:13:56 2024 daemon.notice netifd: TM_5G (5556): +CGEV: ME PDN ACT 1
Wed Jun 12 12:13:56 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:57 2024 daemon.notice netifd: TM_5G (5556): AT+CGPADDR=1
Wed Jun 12 12:13:57 2024 daemon.notice netifd: TM_5G (5556): +CGPADDR: 1,"0.0.0.0.0.0.0.0.10.210.41.81.127.35.165.75",""
Wed Jun 12 12:13:57 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:58 2024 daemon.notice netifd: TM_5G (5556): AT+GTDNS=1
Wed Jun 12 12:13:58 2024 daemon.notice netifd: TM_5G (5556): +GTDNS: 1,"253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.9","253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.16"
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Interface 'TM_5G' is now up
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Network alias 'eth1' link is up
Wed Jun 12 12:13:58 2024 daemon.notice netifd: TM_5G (5556): JSON: { "name": "TM_5G6", "ifname": "@TM_5G", "proto": "dhcpv6", "metric": 25, "extendprefix": "1", "dns": [ "fd00:976a:0000:0000:0000:0000:0000:0009", "fd00:976a:0000:0000:0000:0000:0000:0010" ], "zone": "wan" }
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Interface 'TM_5G6' is enabled
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Interface 'TM_5G6' has link connectivity
Wed Jun 12 12:13:58 2024 daemon.notice netifd: Interface 'TM_5G6' is setting up now
Wed Jun 12 12:13:58 2024 daemon.notice netifd: TM_5G (5556): OK
Wed Jun 12 12:13:58 2024 daemon.err odhcp6c[6365]: Failed to send RS (Address not available)
Wed Jun 12 12:13:58 2024 user.notice firewall: Reloading firewall due to ifup of TM_5G (eth1)
Wed Jun 12 12:13:59 2024 daemon.err odhcp6c[6365]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Jun 12 12:14:00 2024 daemon.warn dnsmasq[1]: possible DNS-rebind attack detected: dns.msftncsi.com
Wed Jun 12 12:14:00 2024 daemon.warn dnsmasq[2]: possible DNS-rebind attack detected: dns.msftncsi.com
Wed Jun 12 12:14:00 2024 daemon.err odhcp6c[6365]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Jun 12 12:14:12 2024 daemon.notice netifd: Interface 'TM_5G6' is now up
Verizon/US Mobile FM350 5G
Wed Jun 12 12:25:03 2024 daemon.notice netifd: Interface 'TM_5G' is setting up now
Wed Jun 12 12:25:04 2024 daemon.notice netifd: TM_5G (9955): Initiate modem with interface eth1
Wed Jun 12 12:25:06 2024 daemon.notice netifd: TM_5G (9955): SIMcard ready
Wed Jun 12 12:25:10 2024 daemon.notice netifd: TM_5G (9955): Configure modem
Wed Jun 12 12:25:22 2024 daemon.notice netifd: TM_5G (9955): Activate modem
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CIREPI: 1
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CNEMIU: 0
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CEREG: 2,"FD07","03DC4C01",7,0,18
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): offline -> searching TAC: 64775 eNodeB: 253004-1 - Reject cause: 18
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CEREG: 1,"FD07","03DC4C01",7,0,0
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): searching -> registered - home network, TAC: 64775 eNodeB: 253004-1
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CTZV: -16,1
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +CEREG: 1,"FD07","03DC4C0C",13,0,0
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): Cell change, TAC: 64775 eNodeB: 253004-12
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): RATchange: -> LTE-ENDC
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): AT+COPS?
Wed Jun 12 12:25:24 2024 daemon.notice netifd: TM_5G (9955): +COPS:0,2,"311480",13
Wed Jun 12 12:25:25 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:25 2024 daemon.notice netifd: TM_5G (9955): AT+COPS=3,0
Wed Jun 12 12:25:25 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:26 2024 daemon.notice netifd: TM_5G (9955): AT+COPS?
Wed Jun 12 12:25:26 2024 daemon.notice netifd: TM_5G (9955): +COPS:0,0,"US Mobile",13
Wed Jun 12 12:25:26 2024 daemon.notice netifd: TM_5G (9955): Registered to US Mobile PLMN:311480 on LTE-ENDC
Wed Jun 12 12:25:26 2024 daemon.notice netifd: TM_5G (9955): Activate session
Wed Jun 12 12:25:26 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:27 2024 daemon.notice netifd: TM_5G (9955): AT+CGACT=1,1
Wed Jun 12 12:25:27 2024 daemon.notice netifd: TM_5G (9955): +CGEV: ME PDN ACT 1
Wed Jun 12 12:25:27 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:28 2024 daemon.notice netifd: TM_5G (9955): AT+CGPADDR=1
Wed Jun 12 12:25:28 2024 daemon.notice netifd: TM_5G (9955): +CGPADDR: 1,"100.81.11.33","0.0.0.0.0.0.0.0.0.0.0.36.247.162.37.1"
Wed Jun 12 12:25:28 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:29 2024 daemon.notice netifd: TM_5G (9955): AT+GTDNS=1
Wed Jun 12 12:25:29 2024 daemon.notice netifd: TM_5G (9955): +GTDNS: 1,"198.224.146.119","198.224.147.135"
Wed Jun 12 12:25:29 2024 daemon.notice netifd: TM_5G (9955): +GTDNS: 1,"32.1.72.136.0.54.255.0.3.162.0.13.0.0.0.0","32.1.72.136.0.55.255.0.3.167.0.13.0.0.0.0"
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Interface 'TM_5G' is now up
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Network alias 'eth1' link is up
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver 192.168.1.1#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver 198.224.146.119#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver 198.224.147.135#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver fd00:976a::9#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver fd00:976a::10#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using nameserver 192.0.0.1#53
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Wed Jun 12 12:25:29 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Wed Jun 12 12:25:29 2024 daemon.notice netifd: TM_5G (9955): JSON: { "name": "TM_5G6", "ifname": "@TM_5G", "proto": "dhcpv6", "metric": 25, "extendprefix": "1", "dns": [ "2001:4888:0036:ff00:03a2:000d:0000:0000", "2001:4888:0037:ff00:03a7:000d:0000:0000" ], "zone": "wan" }
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Interface 'TM_5G6' is enabled
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Interface 'TM_5G6' has link connectivity
Wed Jun 12 12:25:29 2024 daemon.notice netifd: Interface 'TM_5G6' is setting up now
Wed Jun 12 12:25:29 2024 daemon.notice netifd: TM_5G (9955): OK
Wed Jun 12 12:25:29 2024 daemon.err odhcp6c[10851]: Failed to send RS (Address not available)
Wed Jun 12 12:25:29 2024 user.notice firewall: Reloading firewall due to ifup of TM_5G (eth1)
T-Mobile postpaid 5G:
Wed Jun 12 19:29:19 2024 daemon.notice netifd: TM_5G (7283): SIMcard ready
Wed Jun 12 19:29:20 2024 daemon.notice netifd: TM_5G (7283): Configure modem
Wed Jun 12 19:29:33 2024 daemon.notice netifd: TM_5G (7283): Activate modem
Wed Jun 12 19:29:33 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:35 2024 daemon.notice netifd: TM_5G (7283): +CIREPI: 0,0
Wed Jun 12 19:29:35 2024 daemon.notice netifd: TM_5G (7283): +EONSNWNAME: 1, 0, "T-Mobile", 0, "T-Mobile"
Wed Jun 12 19:29:35 2024 daemon.notice netifd: TM_5G (7283): +CTZV: -16,1
Wed Jun 12 19:29:36 2024 daemon.notice netifd: TM_5G (7283): AT+COPS?
Wed Jun 12 19:29:36 2024 daemon.notice netifd: TM_5G (7283): +COPS:0,2,"310260",11
Wed Jun 12 19:29:36 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): AT+COPS=3,0
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): AT+COPS?
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): +COPS:0,0,"T-Mobile",11
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): Registered to T-Mobile PLMN:310260 on 11
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): Activate session
Wed Jun 12 19:29:37 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:39 2024 daemon.notice netifd: TM_5G (7283): AT+CGACT=1,1
Wed Jun 12 19:29:39 2024 daemon.notice netifd: TM_5G (7283): +CGEV: ME PDN ACT 1
Wed Jun 12 19:29:39 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:40 2024 daemon.notice netifd: TM_5G (7283): AT+CGPADDR=1
Wed Jun 12 19:29:40 2024 daemon.notice netifd: TM_5G (7283): +CGPADDR: 1,"0.0.0.0.0.0.0.0.10.210.41.81.129.167.193.160",""
Wed Jun 12 19:29:40 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:40 2024 daemon.notice netifd: TM_5G (7283): AT+GTDNS=1
Wed Jun 12 19:29:40 2024 daemon.notice netifd: TM_5G (7283): +GTDNS: 1,"253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.9","253.0.151.106.0.0.0.0.0.0.0.0.0.0.0.16"
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Interface 'TM_5G' is now up
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Network alias 'eth1' link is up
Wed Jun 12 19:29:41 2024 daemon.notice netifd: TM_5G (7283): JSON: { "name": "TM_5G6", "ifname": "@TM_5G", "proto": "dhcpv6", "metric": 25, "extendprefix": "1", "dns": [ "fd00:976a:0000:0000:0000:0000:0000:0009", "fd00:976a:0000:0000:0000:0000:0000:0010" ], "zone": "wan" }
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Interface 'TM_5G6' is enabled
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Interface 'TM_5G6' has link connectivity
Wed Jun 12 19:29:41 2024 daemon.notice netifd: Interface 'TM_5G6' is setting up now
Wed Jun 12 19:29:41 2024 daemon.notice netifd: TM_5G (7283): OK
Wed Jun 12 19:29:41 2024 daemon.err odhcp6c[4367]: Failed to send RS (Address not available)
Wed Jun 12 19:29:41 2024 user.notice firewall: Reloading firewall due to ifup of TM_5G (eth1)
Wed Jun 12 19:29:41 2024 daemon.err odhcp6c[4367]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Jun 12 19:29:42 2024 daemon.err odhcp6c[4367]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Jun 12 19:29:55 2024 daemon.notice netifd: Interface 'TM_5G6' is now up
With the Verizon SIM in the FM350 and a T-Mobile SIM in the LTE card, these are what I have for my interfaces. wwan0 is the LTE/EC25-AF card while eth1 is the FM350.
10: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
link/[65534]
inet 192.0.0.2/27 brd 192.0.0.31 scope global wwan0
valid_lft forever preferred_lft forever
inet6 2607:fb91:160a:4a4:71b0:2db7:394b:fcf6/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::314:bd2f:c694:32c6/64 scope link flags 800
valid_lft forever preferred_lft forever
12: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
link/ether 00:00:11:12:13:14 brd ff:ff:ff:ff:ff:ff
inet 100.81.11.33/30 brd 100.81.11.35 scope global eth1
valid_lft forever preferred_lft forever
inet6 2600:1009:b061:6112:200:11ff:fe12:1314/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::200:11ff:fe12:1314/64 scope link
valid_lft forever preferred_lft forever
The 192 address is kinda throwing a red flag for me currently. In the past I've seen different IPs in the 1xx.xx.xx.xx ranges, never an obvious private IP like that. But it seems to route data fine. Ignore me. Refreshed my memory on private IP ranges. 192.168.x.x is the only private one so this 192.0.x.x is public.
That all said, the software side seems fine so thanks a lot for these packages. Seems to run quite well when I actually have a working SIM to use.
@cr08 great to read you got it the FM350 working!
I'm struggeling to get my two FM350 (1x DELL 5931e/FM350 / 1x Lenovo FM350) working (eSIM: device canges to diabled mode / USIM: device says SIM card is locked - in both cases FCC unlock does seem to be not successful)
May I ask you to share information about the packages, hardware, OpenWRT version and scripts you took to have your card running?
Thanks!
for the record: my system is a BananaPi BPi-R4 v1.1 with OpenWrt SNAPSHOT r26608 / Kernel 6.6.32
It is not. It comes from 464XLAT.
There is one difference between the T-Mobile and the Verizon/US Mobile SIMs.
When you use the T-Mobile SIMs in the FM350 you are connected to 5G Stand Alone,
11 = NR, NewRadio. 5G Stand Alone.
The Verizon/US Mobile SIM connects to LTE
13 = LTE + NR dual connectivity
Maybe T-Mobile only assign IPv6 when you are connected to 5G SA.
When you use the T-Mobile SIM in the EC25-AF LTE card you don´t have any 5G support.
Is it possible to force the FM350 to only use LTE, not 5G, and see if you get IPV4 from T-Mobile?
@nextgen-networks I will have to get back to you on that one. I've been all over the place with this setup from an x86 machine with a native M.2 slot to now working on a Pi 4 with M.2 USB adapters, different versions of OpenWRT (Stock 23.05.3, snapshots, and a couple of forks including SmoothWAN and OpenMPTCPRouter. Intending to do connection bonding here.). But I do recall at some point something was set up that did the FCC unlock automatically for me different from the guides posted here (The previously linked files for modemmanager seem to be focused on the PCIe side of the card and not USB mode based off the device IDs) and during that I think I manually went through and used the appropriate AT commands to do a permanent unlock. But I'll definitely put some effort into trying to figure out what I did as it would make for good documentation (I'm all about documentation!)
@AndrewZ Yeah. I mis-worded but that was what I was assuming. I noticed the same address range being used on my personal phone (Pixel 6a) with the T-Mobile postpaid SIM. I did try adding the 464XLAT package to OpenWRT and toyed with it for a bit but didn't get anywhere. May not even be the right track here but figured I'd make the attempt either way.
@mrhaav Good catch! Kinda odd considering the FM350 had worked and pulled a V4 address on this SIM before moving to the Pi. I'm not sure if maybe during some of my toying with various things I may have set something by mistake. I do know I've previously had a few cellular modem related Luci packages installed including a band selection tool so MAYBE it switched something? But I'll do a deep dive on this and read over the AT commands and see what I can figure out and report back. I have a funny feeling this might be the cause at least based on some anecdotes I'm seeing around various forums regarding T-Mobile's network setup and V6/V4 usage.