Go Back   DaemonForums > Miscellaneous > Guides

Guides All Guides and HOWTO's.

Thread Tools Display Modes
  #1   (View Single Post)  
Old 10th February 2013
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 996
Default TRENDnet TFM-561U 56k USB modem

This a combination mini-review of the TRENDnet TFM-561U USB 56k dialup modem and guide for its use with some Unix-like OSs. All architectures are i386.


Recently my 10+ year old dialup modem began to connect very erratically. It's a controller-based US Robotics (3Com) 3CP5609 PCI modem. After some investigation I decided to replace it. The available alternatives I considered were:

(a) A similar internal modem, the USR 5610C ($70);

(b) A USB modem, the USR5637 ($46);

(c) A USB modem, the TRENDnet TFM-561U ($30), reviewed here.

I decided on the TRENDnet because it was cheapest and, as a USB modem, could easily be used on different machines if needed.

Crucially, it needs to be usable on Unix-like operating systems. Some googling turned up conflicing reports about support under Linux (some said yes, some no) and no reports about NetBSD or OpenBSD. The more credible sounding Linux reports were positive, and the manufacturer claims it works with Linux, so I decided to give it a try and return it if it didn't work as advertised.

I've found the following:

* works with Linux out of the box;

* works with OpenBSD out of the box;

* works with NetBSD, but you need to hack the umodem(4) driver slightly and recompile the kernel.

Below I'll flesh out the details of the above for each OS.

Mini-Review of TFM-561U

As for the hardware itself, it's based on a Conexant Systems (Rockwell) chipset implementing the CDC-ACM (Communications Device Class - Abstract Control Model). In practice I've found it connects well and stably. It also comes with a small plastic cover that you can put on the USB connector to protect it when not in use.

There are two issues to note that could be better though:

1) Contrary to a report on the Internet, the TRENDnet modem does not seem to have a speaker. I've tried the AT commands to enable sound, such as


and get no squeals. This is not normally a big deal, but would be useful on occasion.

2) It doesn't support the full Hayes AT command set. For example, extended result code commands (e.g., AT&A3) give an ERROR. So there seems to be no way of getting anything like


where 44000 is the modem-modem (DCE) connect speed. Instead, what you'll get is something like

CONNECT 115200

which shows the (useless) modem-computer (DTE) connect speed. This could be a problem when checking out new dialup numbers. Hey, did I mention this is a cheap modem?


How to use the TFM-561U with Linux depends on the kernel vintage. I haven't tried it with a 2.4 series kernel or older. I'll break the discussion into two parts, which derive from Slackware systems. In either case the cdc-acm code must be used; it's often supplied as a module.

Linux (Slackware 12.2 lineage)

The cdc-acm module loads automatically; from the dmesg:

cdc_acm: Zero length descriptor references

cdc_acm: probe of 1-1.3:1.0 failed with error -22
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
However, this alone doesn't create a tty through which to access the modem. For that, you need to follow the (cryptic and bizarre) instructions that actually come with the modem (on page 17 of the User Guide). Specifically, the usbserial module must be loaded, either by hand

# modprobe usbserial vendor=0x0572 product=0x1329

or similarly enabled in rc.modules.local.

This will create the needed tty, such as /dev/ttyUSB0 (which can be linked to /dev/modem).

Linux 3.2.33 (Slackware 14.0 lineage) and

Again cdc-acm is needed and will auto-load, but now in these newer kernels you don't need usbserial anymore. The needed tty is created by cdc-acm, although it has a different name, like /dev/ttyACM0 . From the dmesg:

[    9.248664] usb 1-1.3: new full-speed USB device number 3 using uhci_hcd
[    9.321809] ppdev: user-space parallel port driver
[    9.459317] usb 1-1.3: New USB device found, idVendor=0572, idProduct=1329
[    9.459430] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    9.459559] usb 1-1.3: Product: USB Modem
[    9.459642] usb 1-1.3: Manufacturer: Conexant
[    9.459726] usb 1-1.3: SerialNumber: abcdefgh
[   11.097771] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[   11.110867] usbcore: registered new interface driver cdc_acm
[   11.111128] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Note that this tells you the ttyACM0 device name. Using this device as /dev/modem things also work fine. Here's a udev rule that creates two links to it:

KERNEL=="ttyACM?", SUBSYSTEM=="tty", SYMLINK+="modem modem-usb"
OpenBSD 5.1

The modem is recognized and configured, from the dmesg:

usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
umodem0 at uhub4 port 1 configuration 1 interface 0 "Conexant USB Modem" rev 1.10/1.00 addr 2
umodem0: data interface 1, has no CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0
So the device chain is something like (in this case):

uhub4 --> umodem0 --> ucom0

Then you can talk to the modem with the userland ppp(8) program in terminal mode using the device /dev/cuaU0. I've established a working PPP connection with it using ppp(8).

I haven't checked pppd(8), though am confident it will work, possibly requiring the "local" rather than "modem" flag (see NetBSD discussion).

NetBSD 6.0.1

Unfortunately this does not work out of the box, which was a bit surprising because the NetBSD and OpenBSD drivers are very closely related (first developed on NetBSD). However, it seems the OpenBSD drivers are now more comprehensive in this area. In three versions of NetBSD that I tried (5, 6.0, 6.0.1) this type of dmesg output was obtained:

uhub2 at uhub0 port 1: vendor 0x1a40 USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2
uhub2: 7 ports with 7 removable, self powered
ugen0 at uhub2 port 3
ugen0: Conexant USB Modem, rev 1.10/1.00, addr 3
Here ugen(4) is attaching to the USB hub, where umodem(4) is really wanted. ugen(4) is a default driver that's used when no more specific driver attaches to the device. In order to get the umodem(4) driver to attach, I had to modify the kernel source code file sys/dev/usb/umodem.c, specifically, the umodem_match() function:

int     pass=0;

umodem_match(device_t parent, cfdata_t match, void *aux)
        struct usbif_attach_arg *uaa = aux;
        usb_interface_descriptor_t *id;
        int cm, acm;

           Hack to support TRENDnet TFM-561U
        if (uaa->vendor == 0x0572 &&    /* "USB_VENDOR_CONEXANT" */
            uaa->product == 0x1329) {   /* "USB_PRODUCT_CONEXANT_TFM561U" */
                if( pass == 0 ) {
                        pass = !pass;
                        return (UMATCH_NONE);
                else {
                        pass = !pass;
                        return (UMATCH_VENDOR_PRODUCT);
        if (uaa->class != UICLASS_CDC ||

            uaa->subclass != UISUBCLASS_ABSTRACT_CONTROL_MODEL ||
            uaa->proto != UIPROTO_CDC_AT)
                return (UMATCH_NONE);

        id = usbd_get_interface_descriptor(uaa->iface);
        if (umodem_get_caps(uaa->device, &cm, &acm, id) == -1)
                return (UMATCH_NONE);

My changes are shown in color. Basically they special-case the TRENDnet device and match it on the second instance (there is a first instance with no data port, which I reject for simplicity). Obviously this is a quick hack and something better should be done, but it does prove the modem will work.

With this change to a recompiled GENERIC kernel, umodem0 (instead of ugen0) attaches to uhub2:

uhub2 at uhub0 port 1: vendor 0x1a40 USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2
uhub2: 7 ports with 7 removable, self powered
umodem0 at uhub2 port 3 configuration 1 interface 1
umodem0: Conexant USB Modem, rev 1.10/1.00, addr 3, iclass 10/0
umodem0: data interface 1, has CM over data, has break
ucom0 at umodem0
Now you can access the modem via /dev/ttyU0 or /dev/dtyU0 (both configured by ucom0).

After doing this I had one further problem. Trying to establish an Internet connection using pppd(8), it would seem to dial up and then immediately drop the connection. This turned out to be from using the pppd(8) parameter "modem". I had to change this to its opposite, "local" (see the pppd(8) man page), and then it worked.

I didn't need to switch to "local" under Linux. I didn't try pppd(8) under OpenBSD with the TRENDnet, so "local" might be needed there too.

Last edited by IdOp; 13th February 2013 at 05:09 AM.
Reply With Quote
  #2   (View Single Post)  
Old 18th November 2014
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 996

Update: The modem is now recognized out-of-the-box by NetBSD 7.0_BETA.
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
HSDPA Modem, MF626i player1 OpenBSD General 3 12th June 2011 10:57 PM
modem network. ros2468 OpenBSD General 12 15th March 2010 12:06 PM
proftpd and ppp modem mtx General software and network 3 11th June 2008 11:33 AM
USB EV-DO modem support Bruco FreeBSD General 1 6th June 2008 09:50 PM
Choosing a modem for freebsd 7.0 Johnny2Bad General Hardware 3 6th May 2008 02:44 AM

All times are GMT. The time now is 05:59 AM.

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick