Re: Modem connection help : Multi-Tech MTCBA-G-EN-F4

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.