Quozl's Maxon MM-5100 & MM-5500U on Linux

| quozl@us.netrek.org | up |

Scope: Linux with Maxon MM-5100 or MM-5500U modems.


Requires the cdc-acm kernel module, appears as /dev/ttyACM0, uses the AT command set just like other modems, and works fine with ppp. An additional initialisation string AT+CRM=150 is needed to use a 1x RTT packet switched call.


Update - Community Support Page

If you'd like to contribute, please see the separate Wiki Community Support Page. Use the Login link to create an account on the Wiki, then edit the page to add anything on-topic. You can also subscribe to the page so that you receive changes, or add the RecentChanges RSS feed to your aggregator. Quozl and others will remove off-topic information, or edit the contributions so that they are succinct.


Update - Ubuntu CHAP

David Barton got his MM-5100U working on Ubuntu 5.10, selecting CHAP manually in pppconfig.

It's a measure of success of this page when someone writes thanking me saying they got it working in ten minutes:


Update - PPP Renegotiations

One of the annoying problems has come back harder than ever; and it corresponded with my adoption of the satellite service. The connection spontaneously renegotiates, causing another call record in Telstra's service. It appears to happen as a result of packets that the NAT implementation won't understand; packet traces so far have shown the following to be probable triggers;

I'm working with some experts on the PPP Mailing List. You can see the current thread.


Update - Maxon Mini-Max

Craig Farrier wrote to me to say that the Maxon Mini-Max worked fine for him, he tested on Novell Linux Desktop V9.0. "The USB card was detected as a Qualcom CDMA Modem. I set it up in YAST and configured it to dial a PPP connection and presto I was online. The only thing is I will add AT+CRM=150 before it dials to get it to do 1xRTT."


Update - tcp_sack

An apparent recent change to either the kernel I'm running ( or the Telstra service, requires tcp_sack in /proc/sys/net/ipv4 to be set to zero. The symptom is connections that stall, even though other connections work. The cause seems likely to be the kernel, since there is a packet that arrives that the kernel ignores, but I haven't diagnosed it yet.



Quozl is using a Maxon MM-5100 modem with Linux to access the Telstra CDMA 1x RTT service. Quozl's Maxon modem is based on the Qualcomm MSM5100 chipset, has a USB interface, and two RS-232 serial interfaces on a 15-pin high density connector.

Others are using an MM-5500U; which is a faster EVDO version, with only USB interface.

Figure 1 - Maxon MM-5100 with supplied USB cable, power on

Figure 1 - Maxon MM-5100 with supplied USB cable, power on


Requires the cdc-acm kernel module, appears as /dev/ttyACM0, uses the AT command set just like other modems, and works fine with ppp. An additional initialisation string AT+CRM=150 is needed to use a 1x RTT packet switched call.


  1. Linux distribution: Debian GNU/Linux

    (tested on this distribution, and it worked, and since most of the functionality is part of the kernel and PPP program, expect it to work on other recent distributions)

  2. Linux kernel: 2.6.8, 2.6.9, 2.6.10

    (tested on these versions, and it worked, tests haven't been attempted on other kernel versions yet, reports welcome to quozl@us.netrek.org)

  3. Linux packages (mandatory): ppp

    (you need this package to establish an internet connection)

  4. Linux packages (optional): hotplug, udev, and pppconfig

    (these packages make configuration much easier)


  1. connect modem using USB cable.

    The "pwr" light on the modem should turn on. Shortly after, the "rssi" light should begin to indicate the received signal strength, and if you are in CDMA 1x RTT coverage the "1x cell" light will appear.

  2. check that a /dev/ttyACM0 device is created.

    When the kernel USB driver detects the modem, the hotplug program will load the cdc-acm module, and run the udev program to create the device file. If you don't have hotplug and udev you can create a device node manually with mknod /dev/ttyACM0 c 166 0

    According to usb/acm.txt in the kernel documentation, if you're using devfs then the device will be /dev/usb/acm/0 instead of /dev/ttyACM0.

  3. (for an MM-5500U you may need to use minicom to reset the modem; we're not sure why yet, but we're looking into it)

  4. configure PPP using pppconfig

    Manually Select Modem Port/dev/ttyACM0
    Passwordtelstra (per page 15 of the manual)

    This created two configuration files, /etc/ppp/peers/name and /etc/chatscripts/name, where name is the name you set for the connection.

  5. edit /etc/chatscripts/name to issue an AT+CRM=150 command before dialling ... this directs the modem to use 1x RTT rather than a circuit switched call.

    You can also edit /etc/chatscripts/name to capture the received signal strength indicator and antenna level on each connection attempt. Here are the files:

  6. start the connection the first time using pon updetach debug dump.

    This generates lots of information, just in case something goes wrong and you want to work out why. It isn't necessary to do it every time. The updetach option makes PPP wait until the connection is established before finishing the command. The debug and dump options are described in the manual page for pppd(8).

  7. test internet access, e.g. using a web browser or mail client, and when you're finished turn it off using the command poff.

  8. if it all worked, in future start the connection using pon, stop it using poff.

    You can use other programs that start and stop connections. For example, gkrellm has a button you can press, and kppp can do it as well.


  1. $AUD 800 for the MM-5100 modem,
  2. $AUD 99 per month for the service, 50 hours,
  3. there is no call establishment charge, but each call costs at least 15 minutes off your 50 hours, which makes it $AUD 0.50 per call.


  1. CHAP reauthentication.

    Occasionally, the network will send another request for CHAP authentication. PPP on the Linux host responds, and then IPCP allocates a new address. This can repeat. We've seen this happen up to six times in a minute.

    The effect is stalling and timeout of any active TCP/IP connection. Each event shows up as another call on the carrier's billing system, and so this can be quite costly. $AUD 0.50 per event.

    We have pppdumps of one of these events; there's nothing unusual about the byte stream immediately prior to the event, though there does appear to be some illegal packets following the event. The pppdumps can be analysed by Ethereal.

    No fix known. Still waiting for the carrier to return my calls after logging a system fault (3803 946 345). A way to detect the problem early is to use nodetach instead of updetach, since this causes the reauthentication to be visible on the console or terminal that the connection is started from.

    Another method is a kind of deadmans switch, which kills all pppd processes on connection termination; using an /etc/ppp/ip-down.d script.

  2. random beep while connected.

    For no apparent reason, the modem will emit a short beep. This might correlate to an idle link, but we've been unable to prove it. The beep appears to have no effect on the link.

  3. 100% ping loss for 91 seconds.

    Periodically, all inbound traffic will cease. Pinging the peer address on the PPP link results in 100% packet loss. Modem shows transmit packets on the LEDs, but no receive data. After 90 or 91 seconds, the pings begin to be returned, with the sequence number just sent. There's no buffer of pings. Once affected by this symptom, it will repeat during the current call.

    Seen from about 2004-12-24 onwards. We have tcpdumps of these events, which can be analysed by Ethereal.

    Conjecture; new version of concentrator software to fix the reauthentication and billing problem. As of 2005-01-04, we haven't seen problem 1 since 2004-12-24.

  4. no response to AT commands.

    Sometimes the modem will not respond to AT commands send to /dev/ttyACM0. The LEDs on the modem show data is received. Workaround is to disconnect and reconnect the modem.

    (This may also potentially be fixed by using minicom to reset the modem, but we're not sure why yet.)



2006-04-16 Added a link to a Wiki page for community support.
2005-06-03 Added a success report for a Maxon Mini-Max.
2005-03-11 Added some updates from an MM-5500U user who got his modem working with Linux.
2005-01-04 Added a problems section with the difficulties experienced during normal operation.
2004-11-16 An hour long test with the large antenna mounted properly, over 59.8 minutes received 41,393,657 bytes, which is a long run average of 90.13 kilobits per second, or 11.26 kilobytes per second, though during one large download of 37,315,291 bytes gkrellm showed bursts of 12-15 kilobytes per second.
2004-11-10 Added mail address. Linked now from Dave Davey's page.
2004-11-09 Noted the possibility that a system using devfs may see the device as /dev/usb/acm/0.
2004-11-08 Did early morning (00:15) test with small antenna about 200m from Gilgandra CDMA tower, result was 75kbps at an RSSI of 62, ANTLVL of 1. Confirmed the plan pricing with Telstra. Maxon linked to this page. Changed the layout of this page.

2004-11-07 Tested at a home in Gilgandra. Worked fine.

2004-11-06 Tested on mountain top site using large antenna at 2m elevation; RSSI of 72. Tested at new site using small antenna in kitchen; RSSI of 92.

2004-11-05 Tested network capability further at old site. SSH worked fine. PPTP worked fine to employer. The IP assigned to me gave SERVFAIL on reverse lookup. Packet arrival rate was 58kbps. It was quite jerky; watching a tcpdump and gkrellm showed regular pauses. Ethereal graphed bytes per second of one transfer like this;

Lunch time, went to new site. Disappointing results. Despite having five to six bars on the Nokia 6385, the modem did not exceed about 70kbps, a far cry from the 144kbps advertised. The RSSI value was around 82, and ANTLVL was still 1, suggesting insufficient radio conditions.

Curiously, both the small antenna and large antenna gave about the same RSSI.

There was the same pulsing of data rate, and the first hop lag was an average 300ms with 55ms standard deviation.

2004-11-04 Checked courier drop-off point, parcel has arrived. Box unpacked. Contents are a modem, USB cable, plugpack, small antenna, large antenna, booklet, CD, and mounting bracket.

First plug in gave this on kernel 2.6.8;

hub 1-0:1.0: over-current change on port 1
usb 1-1: new full speed USB device using address 2
drivers/usb/class/cdc-acm.c: Ignoring extra header
cdc_acm 1-1:1.0: ttyACM0: USB ACM device
usbcore: registered new driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters

And /proc/bus/usb/devices showed;

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.01 Cls=02(comm.) Sub=00 Prot=00 MxPS=16 #Cfgs= 1
P: Vendor=05c6 ProdID=3100 Rev= 0.00
S: Manufacturer=Qualcomm, Incorporated
S: Product=Qualcomm CDMA Technologies MSM
S: SerialNumber=Serial Number
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=0b(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

Hotplug loaded the cdc_acm module.

/proc/devices shows a new entry 166 ttyACM. But no /dev entry matches. So I installed udev package. Reboot per the recommendation in the package install scripts (allegedly there's a risk of odd things happening, but I didn't try to find out what).

/dev/ttyACM0 appeared this time. Connected using kermit, DTR LED turned on, and was able to issue AT and get back OK.

Attempted ATDT without antenna, response was "NO CARRIER".

Connected small antenna. Response was "$$Voicemail: 0".

Attempted ATDT, destination phone line rang, presented caller ID. Unlike other modems, the call could not be cancelled by hitting enter, and I had to wait for it to time out. The response was "NO CARRIER".

Noted from CDMA information page that PPP configuration may need to issue PPP packets first, and not wait for CONNECT.

Attempted ATDT#777, then a pause, then hit enter a few times. Response was "NO CARRIER".

Attempted #777 call from within pppd. LCP timeout. Probably needs additional setup.

Experimented with some interesting queries; AT$$SWVER? AT$$TIME AT$$ROAMIND AT$$ANTLVL? AT$$RSSI? AT$$CURRSTATE AT$$RFINFO=1 AT$$DIAG_RING=1000 AT$$CALLTIME

Attempted #777 after +CRM=150. This showed that a CONNECT arrives followed by PPP negotiation, contrary to the suggestion already seen above.

Note to self: pulling the USB cable tends to cause the laptop to turn off the power to the USB port until the laptop is power cycled.

Attempted connection via pppd. It works. Was able to ping Yahoo.

Disconnected and checked signal levels. Using little three-inch antenna gave ANTLVL=1 and RSSI=92. Using big two foot antenna gave ANTLVL=1 and RSSI=89. Not a particularly good improvement, but I am testing indoors half way up a mountain.

Bandwidth tests. Gave about 70kbs. Got a 10.x.x.x address.

12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max = 322.9/329.8/351.9 ms

Connection to my web server came from Since the connection did not arrive until the client had issued an HTTP GET, it is probably transparently proxied.

Recommend blue LEDs for the next model! Red LEDs are so ... seventies. But the power budget and drivers might have been a challenge.

PPP debug log

2004-11-01 Modem ordered by telephone on 1st November 2004 from the Armidale Telstra Shop. Estimated delivery date 4th November.

Site tests using a Nokia 6385. For the current site two to three bars, and for the future site six bars.


Figure 2 - Maxon MM-5100 top view, antenna cable on left

Figure 2 - Maxon MM-5100 top view, antenna cable on left

Figure 3 - Maxon MM-5100 antenna end

Figure 3 - Maxon MM-5100 antenna end

Figure 4 - Large antenna mounted on broomstick in bench vice

Figure 4 - Large antenna mounted on broomstick in bench vice

Figure 5 - Large antenna top view

Figure 5 - Large antenna top view

Figure 6 - Large antenna mounting bracket detail

Figure 6 - Large antenna mounting bracket detail


| quozl@us.netrek.org | up |