Tony, do you have any documentation on this modem?
if it's a standard AT modem, it should work out of the box with kannel.
if you go for TCP instead of serial, there are a few things to consider:
a) setting serial port speed is probably out of control
b) hardware handshake etc as well.
But let's dig into your questions:
On 19.06.2008, at 00:08, Tony Kirkham wrote:
I have not been able to make any headway on this. If anyone has any
ideas, that would help, I would greatly appreciate it.
Thanks,
-Tony
On Sat, Jun 7, 2008 at 1:27 PM, Tony Kirkham
<[EMAIL PROTECTED]> wrote:
Hi, guys,
I'm back with more questions. I am still trying to get kannel to
talk to a Multi-Tech MTCBA-G-EN-F4 modem that connects via an
ethernet port.
If you have good knowledge of the smsc_at driver code I could really
use your help.
I think I have (as I wrote it initially...)
I have been hacking away at the smsc_at.c code and have wrapped the
code to detect the modem speed in an
if ( privdata->is_serial ) { ... }
statement so that this won't be attempted because, apparently, you
cannot detect this modems speed.
.. I would assume you should simply skip that part. Same as on fixed
predefined speed.
I thought this would solve my problem but, alas, it did not. I have
now worked my way down into the at2_read_buffer() call and I think
that this is where the problem is occurring. I have placed a few
DEBUG log file writes in locations to show what is happening. I am
completely new to communicating to modems and via raw tcp so I do
not know what should be expected. However, I don't think the
at2_read_buffer() call is getting anything. Below, is a reduced log
file
at2_read_buffer is simply reading whatever bytes are there from your
device. This can be a partial line.
for the at device containing what is written from a startup -
shutdown cycle of bearerbox.
The biggest indicators that I see are that privdata->lib = strange
characters and at2_read_line() never finds an end-of-line character.
this would inicate some kind of problem on your setup/device. Use
telnet to verify by hand.
One thing which could be different on a TCP connection is the end of
line characters.
The at2_read_buffer() call only executes a read the first time for
the first AT command. After that it seems like the state of
something is stuck because the select() call only returns 0 causing
the at2_read_buffer() call to return NULL before the read() is
attempted.
if select() returns 0 this means the remote side has not sent any bytes.
Select() examines the I/O descriptor sets whose addresses are
passed in readfds, writefds, and errorfds to see if some of their
descriptors are ready for reading, are ready for writing, or
have an exceptional condition pending, respectively. The first nfds
descriptors are checked in each set; i.e., the descriptors from
0 through nfds-1 in the descriptor sets are examined. (Example: If
you have set two file descriptors "4" and "17", nfds should not
be "2", but rather "17 + 1" or "18".) On return, select() replaces
the given descriptor sets with subsets consisting of those
descriptors that are ready for the requested operation. Select()
returns
the total number of ready descriptors in all the sets.
So 0 essentially means, no data available to read. That's why read()
is not called because its useless.
If anyone has some insight into this I would greatly appreciate it.
I am using the code in the source download. I have not pulled
anything from the cvs repository.
not much relevant change I would guess.
I would think either your device doesnt talk AT commands or some fancy
protocol or its a ethernet to serial adaptor in it which you have to
configure properly for its speed (speed mismatch between device and
ethernet adaptor).
Withouth proper documentation its impossible to find out.
