Quozl's Maxon MM-5100 & MM-5500U on Linux |
| quozl@us.netrek.org
| up |
|
Scope: Linux with Maxon MM-5100 or MM-5500U modems.
It's a measure of success of this page when someone writes thanking me saying they got it working in ten minutes:
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
(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)
(tested on these versions, and it worked, tests haven't been attempted on other kernel versions yet, reports welcome to quozl@us.netrek.org)
(you need this package to establish an internet connection)
(these packages make configuration much easier)
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.
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.
| Option | Value |
|---|---|
| Manually Select Modem Port | /dev/ttyACM0 |
| Number | #777 |
| User | user@telstra.xstream |
| Password | telstra (per page 15 of the manual) |
| Speed | 230400 |
This created two configuration files, /etc/ppp/peers/name and /etc/chatscripts/name, where name is the name you set for the connection.
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:
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).
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.
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.
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.
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.
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.)
| Date | Change | |||
|---|---|---|---|---|
| 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;
And /proc/bus/usb/devices showed;
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.
Connection to my web server came from 203.43.185.131:32796. 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.
| |||
| 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 3 - Maxon MM-5100 antenna end
Figure 4 - Large antenna mounted on broomstick in bench vice
Figure 5 - Large antenna top view
Figure 6 - Large antenna mounting bracket detail
