|
||||
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.
Background 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 ATL1M1 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 CONNECT 44000/ARQ/V90/LAPM/V42BIS 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? Linux 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 2.6.27.62 (Slackware 12.2 lineage) The cdc-acm module loads automatically; from the dmesg: Code:
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 # 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 2.6.36.4 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: Code:
[ 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 Code:
KERNEL=="ttyACM?", SUBSYSTEM=="tty", SYMLINK+="modem modem-usb" The modem is recognized and configured, from the dmesg: Code:
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 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: Code:
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 Code:
int pass=0; int 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); return (UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO); } With this change to a recompiled GENERIC kernel, umodem0 (instead of ugen0) attaches to uhub2: Code:
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 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. |
|
|
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 |