DSM-G600, DNS-3xx and NSA-220 Hack Forum

dom323 · 2014-10-09 19:57:19

I'm wondering if anyone has tried/succeeded in setting up their DNS-323 or similar NAS as a fax server. It seems like it would be theoretically possible to get a fax modem like this and plug it into the USB port. Then there's HylaFax which could be used as the fax server.

The problems I see are drivers for the fax modem and compiling HylaFax for the DNS-323. Both of those seem pretty difficult to overcome, so I wanted to ask before I tried something that would be a complete waste of time. Thanks.

FunFiler · 2014-10-10 02:14:15

Do people still use fax machines? LOL

For the price of a Printer/Scanner/Fax it would hardly seem worth the effort/money to buy a single function device.

That being said, I'm sure there is software available that could be recompiled fairly easily.

dom323 · 2014-10-10 02:28:39

Haha, yeah, it does seem like it might be better some times to send the information over on a dinosaur.

That said, in the real estate world it's not uncommon to need to send/receive a 40+ page fax. Not something you want to do on your multifunction machine. Believe me, I've tried. In my mind, getting the fax software to compile and work is probably going to be the easy part. My main concern is drivers for the fax modem and getting the DNS-323 to recognize the hardware properly. Any pointers there?

FunFiler · 2014-10-10 02:54:33

My only suggestion is to search for open source Linux based software. I'm sure there used to be a lot out there. The technology didn't change so you may be able to scrounge up some source code.

Mijzelf · 2014-10-10 18:01:39

dom323 wrote:
My main concern is drivers for the fax modem

Do you have a device? I think it's a simple serial device, where all AT commands can be handled in userspace.

If you have one, plug it in your favorite usb box, and see how it's recognized, and which kernel module is used.

dom323 · 2014-10-10 19:53:20

@Mijzelf, thanks for the help. I just bought a TRENDnet TFM-561U (it should arrive early next week). From what I've read, it seems to have decent Linux support, and people have been able to make it work on the ARM based Raspberry Pi, so that's encouraging.

This stuff is pretty new to me. Could you maybe explain the part about seeing which kernel module is used? How would I go about doing that, and what would that tell me? I don't mind doing some reading if there's a good article you could point me to. Thanks again.

Last edited by dom323 (2014-10-10 19:59:15)

Mijzelf · 2014-10-10 21:30:34

For instance, if I plugin an ftdi serial convertor on my Linux box, it shows up in lsusb as

Code:

Bus 002 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

When I execute lsusb -t, it shows up as

Code:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

So the driver is ftdi_sio. More info about it:

Code:

$ modinfo ftdi_sio
modinfo ftdi_sio
filename:       /lib/modules/3.14.18-desktop586-3.mga4/kernel/drivers/usb/serial/ftdi_sio.ko.xz
license:        GPL
description:    USB FTDI Serial Converters Driver
author:         Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>, Andreas Mohr, Johan Hovold <jhovold@gmail.com>
srcversion:     A37CF3664C42EA45842A16A
alias:          usb:v058Bp0028d*dc*dsc*dp*ic*isc*ip*in01*
alias:          usb:v0403pCB08d*dc*dsc*dp*ic*isc*ip*in*
<snip>
alias:          usb:v0403pF608d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0403pF7C0d*dc*dsc*dp*ic*isc*ip*in*
depends:        usbserial,usbcore
intree:         Y
vermagic:       3.14.18-desktop586-3.mga4 SMP mod_unload modversions 586 
parm:           ndi_latency_timer:NDI device latency timer override (int)

When no driver is found, the VID:PID 0403:6001 is the right Google term to search which module should be used.

BTW, this is only the kernel driver. You still need the userland software.

A lot of info can also be obtained from the kernel log. Wen executing dmesg directly (10 sec) after pluggin in the device, it shows:

Code:

[13611.103445] usb 2-2: new full-speed USB device number 3 using uhci_hcd
[13611.283700] usb 2-2: New USB device found, idVendor=0403, idProduct=6001
[13611.283724] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13611.283737] usb 2-2: Product: TTL232R-3V3
[13611.283748] usb 2-2: Manufacturer: FTDI
[13611.283759] usb 2-2: SerialNumber: FTE39BIP
[13613.194501] usbcore: registered new interface driver usbserial
[13613.195937] usbcore: registered new interface driver usbserial_generic
[13613.196793] usbserial: USB Serial support registered for generic
[13613.284969] usbcore: registered new interface driver ftdi_sio
[13613.285579] usbserial: USB Serial support registered for FTDI USB Serial Device
[13613.285996] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[13613.286790] usb 2-2: Detected FT232RL
[13613.286804] usb 2-2: Number of endpoints 2
[13613.286813] usb 2-2: Endpoint 1 MaxPacketSize 64
[13613.286822] usb 2-2: Endpoint 2 MaxPacketSize 64
[13613.286830] usb 2-2: Setting MaxPacketSize 64
[13613.291148] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0

Which shows about the same info.

dom323 · 2014-10-11 01:08:56

Wow, that's very helpful. Thanks for explaining all of that. I'll report back when the modem comes in and I've had a chance to look at it using the tools you mentioned.

dom323 · 2014-10-14 23:39:24

Ok, I got the USB modem in. I first tried plugging it into the DNS-323 and I got some disappointing, but probably expected results:

Code:

$ dmesg | grep usb
usbcore: registered new driver usbfs
usbcore: registered new driver hub
usb 1-1: new full speed USB device using ehci_platform and address 2
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new full speed USB device using ehci_platform and address 3
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new full speed USB device using ehci_platform and address 4
usb 1-1: device not accepting address 4, error -71
usb 1-1: new full speed USB device using ehci_platform and address 5
usb 1-1: device not accepting address 5, error -75
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver

$ lsusb
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

$ lsusb -t
Bus#  2
`-Dev#   1 Vendor 0x0000 Product 0x0000
Bus#  1
`-Dev#   1 Vendor 0x0000 Product 0x0000

Since the DNS-323 clearly didn't recognize the device, I tried it in an Ubuntu virtual machine (I don't have easy access to a native Linux box at the moment). Here is what I found:

Code:

$ lsusb
Bus 001 Device 003: ID 0572:1329 Conexant Systems (Rockwell), Inc.

$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/8p, 12M
    |__ Port 2: Dev 3, If 1, Class=CDC Data, Driver=cdc_acm, 12M

$ dmesg | grep usb
[   22.940811] usb 1-2: new full-speed USB device number 3 using ohci-pci
[   23.448852] usb 1-2: New USB device found, idVendor=0572, idProduct=1329
[   23.448870] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   23.448885] usb 1-2: Product: USB Modem
[   23.448898] usb 1-2: Manufacturer: Conexant
[   23.448910] usb 1-2: SerialNumber: 24680246
[   23.853311] usbcore: registered new interface driver cdc_acm

So, from what I can gather I need the cdc_acm module which the DNS-323 does not seem to have. I'm not really sure what the process is to get that module working, but I'm assuming it's something like what is done to run ffp from a USB stick. In that process one of the steps is to install the USB mass storage module. Am I on the right track? Can anyone point me in the right direction from here?

I found this driver which looks promising (my device ID is listed), but I'm not sure how I can make that work for the DNS-323. Also, on the download page for that driver, I don't see any options for ARM architecture.

On the software front, I've started work trying to get Hylafax+ to compile as an ffp 0.5 package. Right now, I'm working on the dependencies. I have libtiff compiled and ready to go. I'm getting stuck on ghostscript. Assuming I can get that compiled, the next step will be Hylafax+ itself.

Last edited by dom323 (2014-10-14 23:42:45)

Mijzelf · 2014-10-15 14:05:56

You need the cdc_acm.ko kernel module. That will not be supplied with the firmware, so you either have to download it, or compile it yourself. A kernel module needs to be compiled for explicitly the kernel you are running. Here is a page with precompiled modules, but unfortunately /drivers/usb/class/cdc_acm.ko is missing. Yet it is available in the kernel source of 2.6.12.
Here you can find some extra info on this driver.

Normally you need a cross-compiler, the kernel sources and a .config file. Here is info about the GPL sources.
*Maybe* the ffp compiler is sufficient to compile the module. I never tried the 0.5 compiler and 2.6.old kernels. The compiler of 0.7/arm can compile modules for 2.6.31

dom323 · 2014-10-15 20:01:05

Thanks again for the helpful information. I was able to find the GPL sources from D-Link for my specific hardware and firmware version which include the Linux kernel source. But, I am completely out of my depth attempting to compile the module.

When I try to run "make" on the Linux source it complains "arm-linux-uclibc-gcc: Command not found". I found such a command in the GPL sources in a package called "uclibc-toolchain-src-20040609" but the binaries seem to be incompatible with the DNS-323's architecture (I get " cannot execute binary file" when I try to run it). I'm also getting errors about it not being able to find "stdio.h".

All of this is telling me that I don't have a workable build environment setup, but I really have no idea how to set one up. I'm concerned about using the FFP build environment because it uses a different version of gcc. From my reading, when you want to compile a kernel module for a running kernel, the version strings (magic?) have to match exactly. This is the message I got when I tried to load a cdc_acm.ko module compiled for a QNAP NAS:

Code:

cdc_acm: version magic '2.6.33.2 mod_unload ARMv5 ' should be '2.6.12.6-arm1 ARMv5 gcc-3.3'

The gcc version seems to be part of the kernel module version string, and the gcc supplied with ffp is 4.1.2. Once again, the uclibc toolchain package mentioned above seems to be the solution because it has a directory called gcc-3.3.x with source code and binaries, but I have absolutely no idea how to get it working. My next step is to just try to compile it in ffp build environment anyway and see if I can at least get it to compile. Any other pointers from here?

Mijzelf · 2014-10-15 20:42:34

The toolchain in the package is a crosscompiler. It should run on an x86 system.

When you want to use a native compiler instead, edit the makefile. There is a line CROSS_COMPILE or something like that, which should be commented out.

Further you should first execute 'make menuconfig', to activate the cdc_acm module, and then 'make modules'. No need to build the whole kernel. That would cost several hours, on a 323.

dom323 · 2014-10-15 21:20:29

Ok, that makes sense. I found and commented out that line which has solved the "arm-linux-uclibc-gcc: Command not found" error. But I was still running into the can't find stdio.h error. To resolve that I tried:

Code:

export C_INCLUDE_PATH=/ffp/include/bits

That seemed to solve part of the problem, but now I'm stuck with the following errors. Any ideas on where I'm going wrong at this point?

Code:

# make menuconfig
  HOSTCC  scripts/basic/fixdep
In file included from /ffp/include/sys/types.h:217,
                 from scripts/basic/fixdep.c:105:
/ffp/include/bits/endian.h:2:3: error: #error "Never use <bits/endian.h> directly; include <endian.h> instead."
In file included from scripts/basic/fixdep.c:109:
/ffp/include/bits/fcntl.h:22:3: error: #error "Never use <bits/fcntl.h> directly; include <fcntl.h> instead."
In file included from scripts/basic/fixdep.c:112:
/ffp/include/bits/stdio.h:21:3: error: #error "Never include <bits/stdio.h> directly; use <stdio.h> instead."
In file included from /ffp/include/netinet/in.h:365,
                 from /ffp/include/arpa/inet.h:23,
                 from scripts/basic/fixdep.c:115:
/ffp/include/bits/endian.h:2:3: error: #error "Never use <bits/endian.h> directly; include <endian.h> instead."
scripts/basic/fixdep.c: In function 'usage':
scripts/basic/fixdep.c:129: warning: implicit declaration of function 'fprintf'
scripts/basic/fixdep.c:129: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c:129: error: 'stderr' undeclared (first use in this function)
scripts/basic/fixdep.c:129: error: (Each undeclared identifier is reported only once
scripts/basic/fixdep.c:129: error: for each function it appears in.)
scripts/basic/fixdep.c: In function 'print_cmdline':
scripts/basic/fixdep.c:135: warning: implicit declaration of function 'printf'
scripts/basic/fixdep.c:135: warning: incompatible implicit declaration of built-in function 'printf'
scripts/basic/fixdep.c: In function 'grow_config':
scripts/basic/fixdep.c:153: warning: implicit declaration of function 'perror'
scripts/basic/fixdep.c: In function 'use_config':
scripts/basic/fixdep.c:217: warning: incompatible implicit declaration of built-in function 'printf'
scripts/basic/fixdep.c: In function 'parse_config_file':
scripts/basic/fixdep.c:245: warning: pointer targets in passing argument 1 of 'use_config' differ in signedness
scripts/basic/fixdep.c: In function 'do_config_file':
scripts/basic/fixdep.c:267: warning: implicit declaration of function 'open'
scripts/basic/fixdep.c:269: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c:269: error: 'stderr' undeclared (first use in this function)
scripts/basic/fixdep.c: In function 'parse_dep_file':
scripts/basic/fixdep.c:299: warning: pointer targets in passing argument 1 of 'strchr' differ in signedness
scripts/basic/fixdep.c:299: warning: pointer targets in assignment differ in signedness
scripts/basic/fixdep.c:301: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c:301: error: 'stderr' undeclared (first use in this function)
scripts/basic/fixdep.c:305: warning: incompatible implicit declaration of built-in function 'printf'
scripts/basic/fixdep.c: In function 'print_deps':
scripts/basic/fixdep.c:340: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c:340: error: 'stderr' undeclared (first use in this function)
scripts/basic/fixdep.c:346: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c: In function 'traps':
scripts/basic/fixdep.c:369: warning: incompatible implicit declaration of built-in function 'fprintf'
scripts/basic/fixdep.c:369: error: 'stderr' undeclared (first use in this function)
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2

dom323 · 2014-10-15 22:21:36

Ok, this might have been a problem with my build tools. As an experiment, I tried to build an ffp package that I had recently compiled successfully. It failed with the same error (can't find stdio.h). So, I reinstalled several of the ffp compiling packages (gcc, uclibc, kernel-headers, etc.) and now I'm trying to compile the ffp package again.

It looks like it might have solved that problem, but I can't say for sure yet. I'll report back when I know more.

dom323 · 2014-10-15 23:43:05

Ok, the include path problem seems to be solved. I was able to successfully compile an experimental ffp package, so I'm back to trying to compile the kernel module. The new error I'm running into is:

Code:

error: libintl.h: No such file or directory

From my Googling, it seems like this is a problem with gettext. Unfortunately, I came across this post which indicates that the ffp gettext won't be sufficient for compiling the kernel. I also found this discouraging mailing list thread which seems to indicate that there is no way to run "make menuconfig" without an appropriate version of gettext. Am I stuck here? Does anyone know of a way around this?

Mijzelf · 2014-10-16 11:25:20

Well, of course the kernel doesn't use gettext. How could it? But I guess that the configuration menu from 'make menuconfig' needs it. You *can* skip that step, and edit .config manually. Have a look if there is a CONFIG_CDC_ACM=n, or something like that. Change that in CONFIG_CDC_ACM=m (search for other modules for the exact syntax). If cdc_acm is not dependent on other, not enabled modules, this might do the trick. Then you can execute 'make modules'.

And else you'll need an x86 linux box to do the cross compiling.

BTW, any reason why you don't use FFP 0.7?

dom323 · 2014-10-16 23:09:21

Well I guess that Illustrates how little I understand compiling. I was able to find the module flag in the .config file. It was listed as

Code:

# CONFIG_USB_ACM is not set

I changed that to

Code:

CONFIG_USB_ACM=m

However, when I ran 'make modules' I ran into the same problem (can't find libintl.h). My new plan is to try to compile an ffp package of gettext that would include the library. Failing that, I plan to try to get a cross compiling environment setup in a virtual machine. The guide here seems like a good place to start. I'll report back when I have tried these ideas.

Regarding FFP 0.7, I tried to get it working a while ago, but I ran into problems. I can't remember exactly what it was now, but I think I wasn't able to get a working build environment, so I couldn't make my own packages. It seemed like it was geared more towards newer hardware to me, and it didn't feel quite right on my DNS-323, but that was just my impression.

In other news, I was finally able to get ghostscript to compile as an ffp package ('screen' is my new favorite command). So, the last bit of software I have to build is HylaFAX+, and then the only remaining hurdle *should* be the driver.

As always, thanks for the help.

dom323 · 2014-10-17 23:17:58

Progress! I was finally able to get around the gettext issues and get the kernel modules to compile on my DNS-323. I got a cdc-acm.ko file, but when I tried to load it with "insmod cdc-acm.ko" it failed. This was the error in dmesg:

Code:

cdc_acm: version magic '2.6.12.6-arm1 ARMv5 gcc-4.1' should be '2.6.12.6-arm1 ARMv5 gcc-3.3'

This is what I was afraid of. Everything is perfect except the gcc version. Do you know if there's a way to trick the build process into putting a different version string here? I spent several hours trying to get the cross compiling environment working, and I keep failing to even compile the toolchain. I'm afraid I don't have the skills to make that work, but I'm so close on the native compiling front. Any ideas?

dom323 · 2014-10-18 02:04:23

Success! ...sort of.

Ok, I found the vermagic.h file and hardcoded "gcc-3.3". After that I was able to compile the cdc-acm.ko module and it installed with insmod cdc-acm.ko! Unfortunately, when I plugged in my device it still wasn't recognized. I got a "Zero length descriptor" error when I ran dmesg. After some research, I came across a possible solution. I copied the following from a more recent kernel source (0x0572 seems to be my vendor id and 0x1329 seems to be my product id), and recompiled the module.

Code:

{ USB_DEVICE(0x0572, 0x1329), /* Hummingbird huc56s (Conexant) */
.driver_info = NO_UNION_NORMAL, /* union descriptor misplaced on
                                data interface instead of
                                communications interface.
                                Maybe we should define a new
                                quirk for this. */
},

That seemed to help. Now the device is recognized (although I'm stilling getting a "device descriptor read/64, error -71" see below):

Code:

# cat /proc/bus/usb/devices

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  2
P:  Vendor=0572 ProdID=1329 Rev= 1.00
S:  Manufacturer=Conexant
S:  Product=USB Modem
S:  SerialNumber=24680246
C:* #Ifs= 2 Cfg#= 1 Atr=80 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=  64 Ivl=128ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
C:  #Ifs= 3 Cfg#= 2 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=128ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

Code:

# lsusb

Bus 001 Device 007: ID 0572:1329 Conexant Systems (Rockwell), Inc.

Code:

# dmesg

usb 1-1: new full speed USB device using ehci_platform and address 7
usb 1-1: device descriptor read/64, error -71
usb 1-1: configuration #1 chosen from 2 choices
cdc_acm 1-1:1.0: ttyACM0: USB ACM device

The problem is that I don't see "/dev/ttyACM0", which from my understanding, should be there after plugging in the modem. Following the post here I can run "mknod" to create it, but I don't know if that's the right thing to do. Also, I'm realizing at this point that I have no idea how to test if the thing is even working. The notes you linked for cdc-acm mention "minicom" which I don't have. Any ideas on how to test this? I suppose HylaFAX should be able to test it in some way, but I'm still having trouble compiling that.

Thanks.

Mijzelf · 2014-10-18 12:54:34

Nice! I wonder why the gcc version is included in the 'version magic'. On modern kernels that is no longer the case. Maybe for older gcc versions the produced binary interface changed, while that is no longer the case?

The problem is that I don't see "/dev/ttyACM0", which from my understanding, should be there after plugging in the modem. Following the post here I can run "mknod" to create it, but I don't know if that's the right thing to do.

Yes it is. The device node is not created automagically. You need a special daemon for that (udev, in most cases) to create the nodes. On a single purpose box as a nas, the vendor didn't bother to add such a daemon.
There is no harm in adding it manually. (You'll have to do it on each reboot)

About minicom, I complied it for ffp 0.7/arm, two years ago, and I can't remember there were any quirks. But of course ffp 0.5 is much older (and oabi), so that might give a problem. But you can also convert the serial to network, and use telnet to connect.

dom323 · 2014-10-21 00:06:13

Thanks for explaining that, and for compiling all of those packages for me. I know I already said thanks in the other thread, but seriously, I really appreciate it. I created /dev/ttyACM0 and used your minicom package to test out some AT commands. It worked!

I struggled through /ffp/sbin/faxsetup. I created a setup.sh script to fire during ffp's init process to load the CDC ACM kernel module and create the /dev node. Then, I decided to reboot to test all of that before going forward. My right HDD picks that moment to fail.

My nagging concern is that this can't be a coincidence. Could my kernel module have corrupted something? I've run it without issue on my other DNS-323 for a few days, but this was the first time I've ever tried loading it during boot. I have another drive on order, and I'm hoping that it was just a coincidence and after a quick RAID rebuild, I'll be good to go again.

I'll report back when I'm able to move forward with testing.

Last edited by dom323 (2014-10-21 00:13:18)

Mijzelf · 2014-10-21 11:02:04

dom323 wrote:
My nagging concern is that this can't be a coincidence. Could my kernel module have corrupted something? I've run it without issue on my other DNS-323 for a few days, but this was the first time I've ever tried loading it during boot.

'During boot' is a relative concept. According to the Wiki the script /usr/sbin/chk_fun_plug is called on the last line of /etc/rc.sh, which means the raid array is build, the disks are mounted, all daemons running before this script is called. And then that script starts with a 'sleep 30'.
So if your disk fails on boot, it has nothing to do with a starting ffp.

Theoretically you can't exclude that the module did something nasty regarding the disk (in the previous run). But in practice I don't think so. The module only mounts on an usb socket (if that are the right words) and translates the data to a character device. No interference with disk I/O.
The module is running in kernel space, so due to a bug (or a wrong gcc version) it could corrupt random code. But in that case a kernel crash is much more likely than a 'kill yourself' command through the sata port.

dom323 · 2014-10-24 02:00:50

Ok, well my RAID array has finally rebuilt. I've been fighting with this all day today, and I can't get hylafax to work. It seems to be an issue getting it to talk to my modem. I made it through faxsetup and faxaddmodem. But the probemodem portion wasn't able to determine the baud rate for my modem. When I specify a specific speed it will work, but it can't get info about the modem, and so it has me manually configure it. I have no idea what any of the settings mean, so I'm sure that was done wrong.

The thing is, when it's trying to get info about the modem, it shows the AT commands that it's using "ATI0" "ATI3" etc. When I try running those commands with minicom, they produce what looks like valid info. I guess hylafax just can't communicate with this type of modem for some reason even though minicom can. Even more, with minicom, I'm able to have it call one of my other lines and the phone rings, so it seems like the problem is with hylafax, not the modem or the driver.

When I try to use sendfax I get a SUBMIT JOB X (where X is job number) in the logs, but nothing after that and no fax is sent.

I can get hfaxd and faxq to run, but when I run faxstat I get

Code:

HylaFAX scheduler on NAS-7379C5: Running
Modem ttyACM0 (+1.XXX.XXX.XXXX): Initializing server

From everything I've read, you need to increase the log level and check the logs to see why it hangs at "Initializing server". I've tried everything I can find to do that, but I don't get anything useful in the logs.

From the docs:

Code:

When faxgetty is respawning, 'faxstat' will return:

    HylaFAX scheduler on faxserver.mydomain.com: Running
    Modem ttySx (000-123-4567): Initializing server

When I try to initialize faxgetty, I get a segmentation fault. When I run "strace faxgetty -D ttyACM0" here is what I get

Code:

stat("etc/config.ttyACM0", {st_mode=S_IFREG|0644, st_size=4812, ...}) = 0
open("etc/config.ttyACM0", O_RDONLY)    = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbeacd23c) = -1 ENOTTY (Inappropriate ioctl for device)
brk(0x23000)                            = 0x23000
read(4, "# $Id: class1.0 1085 2012-02-14 0"..., 4096) = 4096
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

The problem seems to come from the ioctl line. It seems to try to be opening the plain text config file as a TTY or something. Honestly, I have no idea what ioctl is or what it's doing, so I could be barking up completely the wrong tree here.

Sorry for the long, rambling post. It's been a frustrating day. Any ideas?

Last edited by dom323 (2014-10-25 01:57:39)

dom323 · 2014-10-24 22:01:13

Well, I just sent my first successful fax from the DNS-323! I was so frustrated with HylaFAX that I went looking for alternatives. I came across a tiny little application called efax. It didn't even come with a ./configure file, so I had to modify the Makefile directly, but it was trivial to prefix everything with /ffp and get it to compile and package up.

I still had to modify the 'fax' bash script a bit, but it had no trouble communicating with the my modem and I was able to send a test fax to FaxToy.com. I still haven't tested the receiving functionality yet, but that's next.

The biggest hurdle now is going to be client support. I originally picked HylaFAX because of all the Windows and Linux client apps available. I haven't looked much, but given how simple efax is, it looks like it will be up to me to figure out clients. Here is what I'm thinking:

- I need a way to send jobs to the efax server. This seems to be accomplished by setting up a PostScript printer and sharing it via SAMBA, but I have no idea how to do that. Also, if I'm "printing" to the fax machine, I'm not sure how to specify the recipient's number. One system I saw involved renaming the file to the recipient's fax number, but that seemed kludgy and error prone. Any ideas here?

- I need a way to notify users when a fax is received. I can hook into efax's system for this (the 'fax' bash script includes a hook where you can call an arbitrary command when a fax is received), but I'd rather not just send the fax's via email (avoiding that is kind of the whole point of why I'm doing this). So, I guess I will need a system to send a notification email, and then provide some kind of user log in system (maybe web based) for the user to login and retrieve their fax. Could be complicated.

Given all the time and effort required to set that up, I would still like to get HylaFAX working, but given how things have been going, I'm not optimistic. Thanks again for all the help getting me this far. Definitely a victory today.

dom323 · 2014-10-24 23:57:52

Just a quick update. I was able to successfully receive a fax, but it wasn't pretty. The only way I could get it to work was by running 'fax answer' and leaving it hanging there while I waited for the call. After the fax came through, I was able to run 'fax2ps [fax file] > temp.ps' (from libtiff) and then 'ps2pdf temp.ps' (from Ghostscript) to get a PDF file of the fax.

The problem is that once the fax came in 'fax answer' died. My initial plan was to just spawn 'fax answer' in an /ffp/start/faxd.sh script. But, it doesn't want to stay alive like a normal daemon. The efax docs recommend using the inittab, but I don't know how to do that on the DNS-323. The docs say to add the following to inittab (I added ffp prefixes):

Code:

s1:45:respawn:/ffp/bin/sh /ffp/bin/fax answer

I found the DNS-323 firmware initab (/etc/initab) and tried adding the entry, but my understanding is that the changes will only take effect on boot. Of course, on boot, I'm guessing my changes will be erased.

Any ideas on what I should do here?

DSM-G600, DNS-3xx and NSA-220 Hack Forum

Announcement

#1 2014-10-09 19:57:19

Using the DNS-323 as a Fax Server

#2 2014-10-10 02:14:15

Re: Using the DNS-323 as a Fax Server

#3 2014-10-10 02:28:39

Re: Using the DNS-323 as a Fax Server

#4 2014-10-10 02:54:33

Re: Using the DNS-323 as a Fax Server

#5 2014-10-10 18:01:39

Re: Using the DNS-323 as a Fax Server

dom323 wrote:

#6 2014-10-10 19:53:20

Re: Using the DNS-323 as a Fax Server

#7 2014-10-10 21:30:34

Re: Using the DNS-323 as a Fax Server

Code:

Code:

Code:

Code:

#8 2014-10-11 01:08:56

Re: Using the DNS-323 as a Fax Server

#9 2014-10-14 23:39:24

Re: Using the DNS-323 as a Fax Server

Code:

Code:

#10 2014-10-15 14:05:56

Re: Using the DNS-323 as a Fax Server

#11 2014-10-15 20:01:05

Re: Using the DNS-323 as a Fax Server

Code:

#12 2014-10-15 20:42:34

Re: Using the DNS-323 as a Fax Server

#13 2014-10-15 21:20:29

Re: Using the DNS-323 as a Fax Server

Code:

Code:

#14 2014-10-15 22:21:36

Re: Using the DNS-323 as a Fax Server

#15 2014-10-15 23:43:05

Re: Using the DNS-323 as a Fax Server

Code:

#16 2014-10-16 11:25:20

Re: Using the DNS-323 as a Fax Server

#17 2014-10-16 23:09:21

Re: Using the DNS-323 as a Fax Server

Code:

Code:

#18 2014-10-17 23:17:58

Re: Using the DNS-323 as a Fax Server

Code:

#19 2014-10-18 02:04:23

Re: Using the DNS-323 as a Fax Server

Code:

Code:

Code:

Code:

#20 2014-10-18 12:54:34

Re: Using the DNS-323 as a Fax Server

#21 2014-10-21 00:06:13

Re: Using the DNS-323 as a Fax Server

#22 2014-10-21 11:02:04

Re: Using the DNS-323 as a Fax Server

dom323 wrote:

#23 2014-10-24 02:00:50

Re: Using the DNS-323 as a Fax Server

Code:

Code:

Code:

#24 2014-10-24 22:01:13

Re: Using the DNS-323 as a Fax Server

#25 2014-10-24 23:57:52

Re: Using the DNS-323 as a Fax Server

Code:

Board footer