Sierra mc73xx Cellular Stats

tanman87

Hello folks, I just recently finished installing my Sierra mc7354 card in my system, and connectivity is up and good on T-Mobile. The question I have now is, is there any way to check cellular stats while the connection is up? I noticed that under Status > Monitoring, I can now select "Cellular" as a category, but all values are 0.

Thanks in advance!

FranciscoFranco

I don't know about the web gui but from the console you can pull up stats from your shell. You would need to use cu for a terminal and feed the modem AT commands. I suggest you browse the MC73xx Extended AT Command PDF. For general info AT!GSTATUS comes to mind.

You might want to buff up on cu. Its shortcut key driven.
cu -l /dev/cuaU0.2

tanman87

Yep, I've downloaded the AT command reference and have dabbled with using cu a bit, and yes, AT!GSTATUS is the kind of info I'm looking for. Unfortunately, while the PPP connection is active, cu reports "all ports busy"

/root: cu -l /dev/cuaU0.2
all ports busy

Am I missing something?

FranciscoFranco

Yes that is right. When the MC7354 was added to usbdevs/u3g0 that bug was introduced. I was using MC7700 at the time and witnessed the change.
I think it has to do with the USB endpoints. In the old days MC7700 used cuaU0.4 for the at command console and cuaU0.3 for a data channel and GPS was on cuaU0.2. When MC7354 hit pfSense my MC7700 AT console moved and ended up on cuaU0.3. At that point iI had exactly what you are seeing.
You lose the AT console when connected but internet works. I think the AT command prompt is riding wrongly on the data channel or endpoint. Just a guess from a non programmer.

At the time I shifted to MC7354/MC7355 and never really tested the console while online.
I used to have access to free SIMs and they dried up so I lost interest.

A PR should be filed upstream but I don't like to complain.

FranciscoFranco

I was just digging through the commits for MC7354/MC7355 and I don't see any changes that would cause this issue. I am looking more at the issue.
https://lists.freebsd.org/pipermail/svn-src-stable/2015-September/029634.html
https://reviews.freebsd.org/D2444?id=5191

Pretty cut and dry. The PID's were added. Nothing else. I am going to look at all the u3g commits around this timeframe to see what else changed.
Funny to see the MC7700 listed as a MC8700. I never could figure if that was a typo or what.

I thought the issue was only on the MC7700. I moved on to MC7355 and never looked back.

FranciscoFranco

Found what I think is the problem:
https://svnweb.freebsd.org/base/head/sys/dev/usb/serial/u3g.c?r1=269569&r2=269568&pathrev=269569

If I get some time I will poke around and see what this patch was for. It seems it broke MC7700 and MC73xx for AT console while connected.
Might contact HPS as he is the usb dev guru who committed this..

Maybe I will get a SIM working and roll back this commit and see what it does.
This patch defiantly affected Sierra endpoints.
I looked at all the patches for u3g and my money is on this being the problem.
https://svnweb.freebsd.org/base/head/sys/dev/usb/serial/u3g.c?view=log

FranciscoFranco

So the more I ponder this issue I come to this conclusion. This patch I referenced did fix the Sierra code u3g.c with \n fixup.
When \n is added the code is correct but the function behaves badly by assigning the AT command console to the wrong endpoint.

This is all a rough guess from a rookie..This is in the quirks section so I might be off base.

tanman87

Sounds logical to me, but what do I know ;D

Anyways, I appreciate the effort!