Netgate 2100 micro sim + 4G LTE / 5G

[mphodge]

Ok, so I rebooted the 2100 with the SIM inserted and now I get:

at+cpin?
+CPIN: READY
OK
at+cimi
204080830238557
OK

However, still no PPP connection. Same logs as previously, tries to connect, authenticates ok, no IP, terminates process.
Have double-checked the APN name which is correct from the SIM supplier.

[stephenw10]

I don't think it's the SIM. Or at least not the connectivity to it. When you tested it without the SIM did you reboot in between? I'm not sure when the modem actually queries it but I'd be amazed it got that far without any SIM present.

[Dobby_]

I saw your picture (2100 with the modem), please connect the antennas even
before your empower the modem, the antennas are grounding the modem
device!!! (electric grounding)

Is this a M.2 modem? Are the antennas also made for M.2 or only for miniPCIe?
There are differences between.

There are two modes DIP (direct IP) or QMI (Qualcomm MSM Interface),
I use a Sierra Wireless 7710 LTE modem and must set it up to the DIP
mode, until it was not working for me in pfSense.

Finding out the mode for my modem was marching this way;

[24.03-RC][root@xxx.xxx]/root: usbconfig
ugen1.1: <AMD EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAV                            E (0mA)
ugen0.1: <AMD XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SA                            VE (0mA)
ugen2.1: <AMD EHCI root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAV                            E (0mA)
ugen1.2: <vendor 0x0438 product 0x7900> at usbus1, cfg=0 md=HOST spd=HIGH (480Mb                            ps) pwr=SAVE (100mA)
ugen2.2: <vendor 0x0438 product 0x7900> at usbus2, cfg=0 md=HOST spd=HIGH (480Mb                            ps) pwr=SAVE (100mA)
ugen2.3: <u-blox AG - www.u-blox.com u-blox 6  -  GPS Receiver> at usbus2, cfg=0                             md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.2: <Sierra Wireless, Incorporated MC7710> at usbus0, cfg=0 md=HOST spd=HIG                            H (480Mbps) pwr=ON (0mA)

[24.03-RC][root@xxx.xxx]/root: usbconfig -d 0.2 dump_device_desc
ugen0.2: <Sierra Wireless, Incorporated MC7710> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x1199
  idProduct = 0x68a3
  bcdDevice = 0x0006
  iManufacturer = 0x0003  <Sierra Wireless, Incorporated>
  iProduct = 0x0002  <MC7710>
  iSerialNumber = 0x0004  <358178041368210>
  bNumConfigurations = 0x0001

This command shows the USB PID

usbconfig -d 0.2 dump_device_desc

68A2 = QMI mode
68A3 = DIP mode

1199:68a2 - MC7710 in QMI mode
1199:68a3 - MC7710 in DirectIP mode

I was using this toll here for setting the modem to the DIP mode:
DIP_QMI mode switch tool

Insert the modem and the SIM card, boot the pfSense, after boot up go via console (Putty) and set up the following commands to find out more;

# connects to the modem
cu -l /dev/cuaU0.2
answer or oputput will be "Connected

# puts the modem in verbose mode
AT+CMEE=2

# Shows the vendor and bands
ATI

# proofing the SIM / PIN
AT+cpin?

# Proofing the signal strength of the Band/Antenna
AT+CSQ

# is scanning the available networks
AT+COPS=?

# Check the mobile phone activity status 
AT+CPAS

# shows the modem.log
tail -f /var/log/ppp.log

You can also try out to set the modem into the DIP mode by using this:

AT!ENTERCND="A710"
AT!UDPID=68A3
AT!RESE

[stephenw10]

Most of that shouldn't be required on the EM7455. Since it's presenting an AT interface it must be running an appropriate composition.

[mphodge]

This is what I get from usbconfig:

[mphodge]

Sorry had to screen shot as the site thought I was posting spam for some reason!
Output from modem:

cu -l /dev/cuaU0.2
Connected

at+cmee=2
OK

ati
Manufacturer: Sierra Wireless, Incorporated
Model: EM7455
Revision: SWI9X30C_02.38.00.00 rE3F3E55C03AE94 jenkins 2022/01/13 05:16:00
MEID: 35399007355869
IMEI: 353990073558699
IMEI SV: 22
FSN: LF641313650210
+GCAP: +CGSM,+DS,+ES
OK

at+cpin?
+CPIN: READY
OK

at+csq
+csq: 8,99
OK

at+cops=?
+cops: (2,"3 UK","3 UK","23420",2),,(0,1,2,3,4),(0,1,2)
OK

at+cpas
+CPAS: 0
OK

The PPP still does not connect. Any ideas for next step?

[stephenw10]

Hmm, this feels like it has to be the provider. Though that's hard to explain because I'm using "3 UK" and it works fine.

Did you test without the SIM in after rebooting? Just make sure it fails earlier in the process.

[Dobby_]

at+cpas
+CPAS: 0
OK

0 = Ready (Mobile Termination (MT) allows commands from Terminal Adapter (TA)/Terminal Equipment (TE))

at+csq
+csq: 8,99
OK

I would have a look here to that tables, they are very good explaining the
signal strength and it may be brings you to change the position of your
pfSense box to get a better or excellent signal strength. Often are antennas with a 1/2 meter cable and a magnetic stand will be able to let the router
where it is but you get also a better signal. LTE Signal strength

at+cops=?
+cops: (2,"3 UK","3 UK","23420",2),,(0,1,2,3,4),(0,1,2)
OK

This are the available networks you may be able to reach from your router.
Here you may be able to see another output with very excellent
area roaming as an example.

+COPS: (1,"3 UK","3 UK","23420",2),(1,"Orange F","Orange","20801",7),
(1,"F-Bouygues Telecom","BYTEL","20820",7),(1,"F SFR","SFR","20810",2),
(1,"Free","Free","20815",7),(1,"Airtel-Vodafone","ATL-VOD","23403",7),
(1,"Airtel-Vodafone","ATL-VOD","23403",2),(1,"JT","JT","23450",7),
(1,"Sure","Sure","23455",7),(1,"JT","JT","23450",2),(1,"Sure","Sure","23455",2),
(1,"vodafone UK","voda UK","23415",2),(1,"EE","EE","23430",2),
(1,"O2 - UK","O2 - UK","23410",2),(1,"208 16","208 16","20816",7),,(0-4),(0-2)

So perhaps you may be put the router to another place to get better results.

3 UK","23420"

But anyway, this is the interesting part for you, the 5 digit number is
presenting your region; 23420 = Hutchinson 3G (3) – United Kingdom

[mphodge]

Ok, thanks for your helpful diagnostics :-)

So, without a SIM card inserted, the PPP logs:

Apr 17 16:18:09 pfSense ppp[57660]: [wan] Bundle: Interface ng0 created
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] Link: OPEN event
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] LCP: Open event
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] LCP: state change Initial --> Starting
...
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] CHAP: Using authname "user"
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] CHAP: sending RESPONSE #1 len: 25
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] CHAP: rec'd SUCCESS #1 len: 4
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] LCP: authorization successful
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] Link: Matched action 'bundle "wan" ""'
Apr 17 16:18:09 pfSense ppp[57660]: [wan_link0] Link: Join bundle "wan"
Apr 17 16:18:09 pfSense ppp[57660]: [wan] Bundle: Status update: up 1 link, total bandwidth 150000000 bps
...
Apr 17 16:18:09 pfSense ppp[57660]: [wan] IPCP: SendConfigReq #1
...
Apr 17 16:18:28 pfSense ppp[57660]: [wan] IPV6CP: SendConfigReq #10
...
Apr 17 16:18:36 pfSense ppp[57660]: fatal error, exiting
Apr 17 16:18:36 pfSense ppp[57660]: [wan] IFACE: Close event
Apr 17 16:18:36 pfSense ppp[57660]: [wan] IPCP: Close event
Apr 17 16:18:36 pfSense ppp[57660]: [wan] IPV6CP: Close event
Apr 17 16:18:36 pfSense ppp[57660]: [wan] Bundle: Shutdown
Apr 17 16:18:36 pfSense ppp[57660]: [wan_link0] Link: Shutdown
Apr 17 16:18:36 pfSense ppp[57660]: process 57660 terminated

What is the LCP authorizing with here if there is no SIM? and how is it successful?

With a known-working SIM inserted and router rebooted, exactly the same up until:

Apr 17 16:43:24 pfSense ppp[86491]: [wan] IPCP: SendConfigReq #2
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   IPADDR 0.0.0.0
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   PRIDNS 0.0.0.0
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   SECDNS 0.0.0.0
Apr 17 16:43:24 pfSense ppp[86491]: [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   IPADDR 10.88.80.91
Apr 17 16:43:24 pfSense ppp[86491]: [wan]     10.88.80.91 is OK
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   PRIDNS 66.28.0.61
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   SECDNS 209.244.0.3
...
Apr 17 16:43:24 pfSense ppp[86491]: [wan] IPCP: state change Ack-Sent --> Opened
Apr 17 16:43:24 pfSense ppp[86491]: [wan] IPCP: LayerUp
Apr 17 16:43:24 pfSense ppp[86491]: [wan]   10.88.80.91 -> 10.64.64.0
Apr 17 16:43:25 pfSense ppp[86491]: [wan] IFACE: Up event
Apr 17 16:43:25 pfSense ppp[86491]: [wan] IFACE: Rename interface ng0 to ppp0
Apr 17 16:43:25 pfSense ppp[86491]: [wan] IFACE: Add description "WAN"

Aha! we finally have an IP address
And WAN interface now shows as up.
I think connecting the correct pigtails gave enough signal strength to finally work.
Only problem now is the IP is private and NAT'd by the provider, so will have to request a public!
Thanks for your help guys.

[stephenw10]

Nice!

Interesting though. I wouldn't expect that login to get nearly that far without a valid SIM.

[Dobby_]

@mphodge said in Netgate 2100 micro sim + 4G LTE / 5G:

Aha! we finally have an IP address

In the interface setup you may be able to set up IPv6 = DHCP
so you may be getting also an IPv6 IP address.

And WAN interface now shows as up.

You can now set up in the WAN settings what you need, failover
or load balancing with failover.

I think connecting the correct pigtails gave enough signal strength to finally work.

You will see this by looking over the download/upload numbers.

Only problem now is the IP is private and NAT'd by the provider, so will have to request a public!

The most consumer contracts will be having this only, but often you will be able to get one together with a small business mobile phone contract.

[aaronouthier]

Apr 15 14:00:57 pfSense ppp[31402]: [wan_link0] LCP: auth: peer wants CHAP, I want nothing

I am far from being an expert, but this looks like an auth mismatch. The carrier expects CHAP auth, but the router is expecting no auth at all. That's what stands out to me in the logs. Again, I'm no expert.

[stephenw10]

I think that only implies we are demanding nothing specific. That same line appears in a successful connection:

Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] LCP: state change Ack-Sent --> Opened
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] LCP: auth: peer wants CHAP, I want nothing
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] LCP: LayerUp
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] LCP: rec'd Discard Request #29 (Opened)
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] CHAP: rec'd CHALLENGE #1 len: 35
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] Name: "UMTS_CHAP_SRVR"
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] CHAP: Using authname "user"
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] CHAP: sending RESPONSE #1 len: 25
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] CHAP: rec'd SUCCESS #1 len: 4
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] LCP: authorization successful
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] Link: Matched action 'bundle "opt1" ""'
Apr 25 01:08:03 	ppp 	43273 	[opt1_link0] Link: Join bundle "opt1" 

[aaronouthier]

@stephenw10

Ahhh. I didn't realize this was solved. Thought OP was still having issues.