DIP/DirectIP is not MBIM in V7. But you’d want MBIM mode on Sierra if possible.
What I’m not sure is if MBIM is even support on the MC7700, I think so. So what does “AT!UDUSBCOMP=?” report when run from serial to the AT port of modem…
e.g. either serial console on your desktop … OR if serial at least is appearing in RouterOS and info channel is correct (likely info-channel=2 on PPP)
/interface/ppp-client/at-chat [find] input=“AT!UDUSBCOMP=?”
or with an LTE interface, you can try:
/interface/lte/at-chat [find] input=“AT!UDUSBCOMP=?”
My guess is you need to do a AT!UDUSBCOMP=7 to get MBIM mode to show up on RouterOS – but those number vary by modem… why the “=?” version of AT will show the possible USB configurations that are possible.
QMI will not work. In theory, DIP (in Linux, CDC-ECM, or “DirectIP” in RouterOS v6) should work… And, I’d make sure you’re on the latest firmware for sure. We know your modem’s serial interface is taking commands, so that good.
And it’s likely in DIP modem, since LTE is showing up – BUT I suspect the LTE interface might confused by that since it may expect a Sierra modem to be MBIM since all the new ones do NOT support DIP. e.g. the MC7700 is a weird one — one the first and last ones to support even DIP (or “DirectIP” or CDC-ECM in Linux as it’s called in RouterOS V7) – they moved on MBIM pretty quick. And Mikrotik has never support Gobi/QMI protocol, which is the default, making it even trickier…
BUT my bad… you need to unlock the Sierra modems to use hardware commands – why the AT!UDUSBCOMP=? is not working – and critical to know what mode the sucker is in…
And either report the output here… or if you see “DIAG NMEA AT MBIM” next one (likely, but not sure, 7 in the list) that what you need in a “AT!UDUSBCOMP=7” command that switch it to MBIM modem (in which case physically unplug/replug power the unit to ensure it takes after doing it)…
Adding logging help too…
/system/logging add topics="lte,!packet"
or to get even less clutter (and not using OR removing the previous one ) the following will log even less LTE stuff:
Here are the outputs, looks like mbim isn’t supported?
Would downgrading to v6 solve this?
**UPDATE: ROS 6.49.8 works much better, I get an IP now on lte1. Trying to bridge lte1 and spf1 now, don’t really know what I am doing
**UPDATE 2: I am stuck at “GSM Compact”, don’t know what it should be. Have not got them bridged yet either.
**UPDATE 3: After moving the setup upstairs I now get “Evolved 3G (LTE)”. Got some traffic moving as well on lte1, will try to connect to internet soon
[admin@MikroTik] > /interface/ppp-client/at-chat [find] input="AT!ENTERCND=\"A710\""
output: AT!ENTERCND="A710"
OK
[admin@MikroTik] > /interface/ppp-client/at-chat [find] input="AT!UDUSBCOMP=?"
output: AT!UDUSBCOMP=?
0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS SUPPORTED
1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED
2 - HIP DM NMEA AT NIC1 MS SUPPORTED
3 - HIP DM NMEA AT MDM1 NIC1 MS SUPPORTED
4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS SUPPORTED
5 - HIP DM NMEA AT ECM1 MS SUPPORTED
6 - DM NMEA AT QMI NOT SUPPORTED
7 - DM NMEA AT RMNET1 RMNET2 RMNET3 NOT SUPPORTED
8 - DM NMEA AT MBIM NOT SUPPORTED
9 - MBIM NOT SUPPORTED
10 - NMEA MBIM NOT SUPPORTED
11 - DM MBIM NOT SUPPORTED
12 - DM NMEA MBIM NOT SUPPORTED
13 - Config1: comp6 Config2: comp8 NOT SUPPORTED
14 - Config1: comp6 Config2: comp9 NOT SUPPORTED
15 - Config1: comp6 Config2: comp10 NOT SUPPORTED
16 - Config1: comp6 Config2: comp11 NOT SUPPORTED
17 - Config1: comp6 Config2: comp12 NOT SUPPORTED
18 - Config1: comp7 Config2: comp8 NOT SUPPORTED
19 - Config1: comp7 Config2: comp9 NOT SUPPORTED
20 - Config1: comp7 Config2: comp10 NOT SUPPORTED
21 - Config1: comp7 Config2: comp11 NOT SUPPORTED
22 - Config1: comp7 Config2: comp12 NOT SUPPORTED
OK
Hmm. RouterOS make guesses on the port mapping based on the USB device ID…
So V6 does not support MBIM modems, so it only looks for DirectIP modems. So from the MC7700 USB device ID, it knows it DIP.
Under V7, it support both DirectIP and MBIM modes. But I’m guess it’s assuming the MC7700 USB device ID are for a MBIM modem – and, generally, that’s what you’d want for the Sierra modems. So it’s not likely looking/trying DIP with for that deviceID. And, while you can force MBIM in the LTE settings, you can’t force DirectIP/CDC-ECM in V7.
The normal solution be switch the modem to MBIM mode. But seems your modem does not support MBIM, at least based on the output. If you’re happy with V6, that may be best.
But if you want to try V7 again… I suppose you can try the AT!ENTERCND command to unlock the modem, then try setting AT!UDUSBCOMP=8 – but I suspect that will return an error since your =? output shows =8 as “NOT SUPPORTED”.
SO…you may need to file a bug at help.mikrotik.com. They may know the right AT!UDPID to set to get RouterOS v7 to recognize the MC7700 as DirectIP. If you file a ticket, you’ll need to try V7 again, and generate a supout.rif. Make sure to add logging suggested above, reboot, and then generate a supout.rif after the reboot – that will have the extra logs during initialization Mikrotik may need.
I would like to use the newest version of all software, including ROS. I have upgraded to v7.11, enabled logging and created a supout.rif after a reboot and submitted a bug.
I did try AT!ENTERCND and thereafter AT!UDUSBCOMP=8, but i got an error on the last command, as expected.
I think the issue is the MC7700 uses the same USB IDs as the other things in the 77xx family – but MC7710,7354,7455 do NOT support DIP, only MBIM. This is likely confusing V7 since it finds detect the modem, but I think it trying to use MBIM even though it’s not supported.
Basically modems work in three modes: serial/PPP, CDC-ECM (aka DIP, DirectIP), and MBIM – but there is no “hey I’m MBIM” messages or anything in USB to the OS. RouterOS/linux has to use USB IDs to know what how USB channels map to know what USB channel# to use for things. BUT modems, Sierra in particular, have a bunch of possible USB channel maps (e.g. the options you see in AT!UDUSBCOMP) for the same USB Device ID…this make is hard for RouterOS/linux since only the modem knows the channel map.
But you can change the USB IDs on the Sierra so your MC7700 look different. I just know know what value you’d need to use a AT!UDPID=XX command to change them that cause Mikrotik to know it’s a DIP (CDC-ECM) modem. But Mikrotik would , why a ticket may be a good idea here.
Yeah… I only know about this since we had a couple MC7700 many years ago…upgraded to using MC7354s etc and found those do NOT support DIP/DirectIP. So any “modern” Sierra modem, other than the MC7700, did not work V6 since it does not have MBIM support. So, yeah, the reverse problem makes sense
Mikrotik uploaded a custom fw to my RB, and now the MC7700 is detected properly as an LTE interface.
I will test it further tomorrow.
**UPDATE: How do I connect spf1 to lte1? Tried some scripts I found on the inteweb, but I don’t really understand what they are doing and hence I can’t really correct them when they don’t work:
**Update 2: Got it on the interweb, used quick set and added a masquerade from the lines below. Stuck at “GSM Compact” for now, even as the signal strength is “excellent”,
I have now gotten LTE connectivity, but with very poor signal strength and 20/2 mbps speed. I have some DNS issues as well that I don’t know how to solve.
Glad they fixed it. I’m actually not sure what LTE stats be shown however, in MBIM mode with Sierra you’d only get an RSSI value to know signal strength. Maybe in DirectIP/DIP/ECM mode you’d get more, since these were support in V6 pretty well and that carried over – dunno.
And since you’re likely very familar with “at-chat” now… “AT!GSTATUS?” will display a range of LTE statics. This will run it in a loop so you can see it changing: http://forum.mikrotik.com/t/mikrotik-lte-sierra-wireless-mc7455/158170/1
(you likely can remove the AT!LTEINFO? one – that’s a newer command that very likely not on the MC7700)
It could also be the antenna configuration and/or position – but if you post the AT!GSTATUS? that help know what the modem things of the RF.
Do you have BOTH antennas wired up? If you’re using terminal antennas, make sure they’re at 90º to each (e.g. like TV rabbit ears from 1970s) to get MIMO effects. If you ran a couple other commands like “AT!CUSTOM?”, “AT!RXDEN?”, and “AT!BAND?” that be helpful to know the config of modem. But assuming you have BOTH antenna wired up, may need to set “AT!RXDEN=1” – but be good know what it was before (e.g. if it was only using primary antenna, that explain speed). (To run any of these, you need the ENTERCND AT command first)
I have two similar antennas, and one big one. Currently using the two small ones. They are not “grounded” to each other as my case is 3d-printed. Is that a problem?
I have been trying different configurations of the antennas:
Both straight up
One up and one straight out
Same as the one over, but the flat one rotated 90 degrees
As a V
As an upside down V
Far appart
There are small changes, but nothing giving me any good coverage.
There is a lot of info in the web fig, see attachment.
Yeah when in DIP/DirectIP mode… RouterOS shows the needed cell signals — that helps here.
The RSRP is what I’d focus on first – -118 is virtually unusable. Even -110 is pretty bad. It’s so low, that if you in a city and/or “close” to some towers, that would point to the antennas/connectors to modem. If you are actually some distance from cell towers/civilization, where you might expect a weak signal…you option there is to get a bigger antennas (or perhaps ones tuned for ~1900MHz)
But I’m not the hardware or antenna guy… But guessing a plastic case have no “ground plane”… So playing with the orientation of antenna is unlikely to change the RSRP that dramatically — that -118 RSRP is just very weak.
Keep in mind it takes at least 10 or more seconds for signals to update after “doing something”. In fact waiting 30 seconds to verify a change in signal from doing something is likely a good idea… e.g. modem talks to tower, modem has to process, and then routeros polls the data periodically – so it’s not instantaneous on the signal levels.
) the following will log even less LTE stuff:
