SMS spam filter [ezx_sms.cfg (Regarding SMS Messages)]

[rhizod]

You realize that you are posting in a thread that is several years old? Just pure luck that I still had a 'notify me on new posts' flag still active on this...

Your code looks really strange; are you sure this is the code you compile? ,can there be some forum formatting error screwing it up?

Look here for example:

    for(i=0; i<2> 0)
   	FD_SET(fd[!i], &obits);
      else
  	 FD_SET(fd[i], &ibits);
      FD_SET(fd[i], &ebits);
    }

Else what? Else-for? Does this even compile? Is this still supposed to be c?

    for(i=0; i<2> 0 */{
			printf("got something from #%d '%s' \n",fd[i],buf[i]);
			bp[i] = buf[i];
		}
	}

A dangling end-of-comment? What has happened with this code? Please look through this again...

Another question:
Is there any other apps read from /dev/mux2 ? And If So, they won't get anything from /dev/mux2.

Not that I really remember any of this from two years back... and showing my limited knowledge of hardware driver design: Wouldn't it be messy to design your hardware gsm modem interface so that you have more than one daemon interacting with it on the same socket? My guess would be that it is the role of tapisrv, and tapisrv alone to open this socket. But I may very well be proven wrong.

So, why are you re-woking this thread? Are you trying to re-do a SMS spam filter without the limitations with mudassars approach?

[glen.redlion]

@rhizod

As I said, I'm a newbie of c programing on unix platform. and my english is pool too.
My question may confused you. I'm really sorry about it.

I tried to write a SMS spam filter, but I don't understand mudassars's approach very well. so far, the only way occurred to me is to hack the firmware. I try to replace tapisrv with my app and then issue the original tapisrv. we can't stop tapisrv so I delay it. make it run after my app.

[rhizod]

@rhizod
As I said, I'm a newbie of c programing on unix platform. and my english is pool too.
My question may confused you. I'm really sorry about it.

No need to be sorry at all! -- The only issue here is that I think you made some kind of copy-paste mistake with the c code above. I don't believe the code you listed is what you compile and run to give you the strange loop behavior. Now please:
1. Make sure you have some c code that compiles and runs and gives you the strange behavior you want help with
2. Please post it here verbatim.

I tried to write a SMS spam filter, but I don't understand mudassars's approach very well. so far, the only way occurred to me is to hack the firmware. I try to replace tapisrv with my app and then issue the original tapisrv. we can't stop tapisrv so I delay it. make it run after my app.

If you want to do this, I really suggest you read this whole thread from start to finish and look at the different ideas and suggestions that are discussed.

In my opinion, the most elegant solution would still be to attach to the running tapisrv, use linux system calls to forcibly swap the connection from /dev/mux2 to your own pseudotty; and so inserting your filter between mux2 and the pseudotty.

In any case, any implementation of a SMS filter will require quite a bit of work.

[glen.redlion]

I lost my code when I tried to paste it.
Any way, It is useless now. It just keep moveing something from fd0 to fd1, then from fd1 to fd0, again and again never stop.

There is a script in /etc/rc.d/rc2.d/ called S45tapsvr.sh. I add a script file called S40filter.sh which links to some file in SD card(If I want the real tapsvr to be run, just remove the SD card), I make it run before S45tapsvr.sh , then make tapsvr to use /tmp/vroot/dev/mux2 instead of /dev/mux2 .

As I know, there is a module called mux_cli. If /dev/mux2 is the interface for mux_cli and user space apps, it regards to not only sms but also phone call and GPRS.

[rhizod]

I lost my code when I tried to paste it.
Any way, It is useless now. It just keep moveing something from fd0 to fd1, then from fd1 to fd0, again and again never stop.

The code you attached now looks much more sane than the one you provided above (that I see that you now have removed).

I see no obvious misstake in the code in itself -- so I think you are just using it wrong... Isn't both mux1 and mux2 device nodes? I don't think it makes sense to copy between those. One of your endpoints should be a pseudotty that you open with a 'openpty' call (or perhaps posix_openpt). See the following linux man pages:
http://www.die.net/doc/linux/man/man3/openpty.3.html
http://www.die.net/doc/linux/man/man7/pty.7.html

So, you should include something like this in your main():

#include <fcntl>
#include <stdio>

int masterfd, slavefd;
char *slavedevice;

masterfd = posix_openpt(O_RDWR|O_NOCTTY);

if (masterfd == -1
   || grantpt (masterfd) == -1
      || unlockpt (masterfd) == -1
      || (slavedevice = ptsname (masterfd)) == NULL) {
      printf("Error opening pseudotty");
      exit(-1);
}

printf("Slave ptty name: %s\n", slavedevice);

And then use 'masterfd' as one of the endpoints to your copy routine, and mux2 as the other. Then you can test the setup by first writing something to the slave ppty printed out when you start your program as "Slave ptty name: xxxx", and then reading from this to see if you get a response passed along from mux2. Is it clear what I mean? Please just ask if you want me to clarify this more.

There is a script in /etc/rc.d/rc2.d/ called S45tapsvr.sh. I add a script file called S40filter.sh which links to some file in SD card(If I want the real tapsvr to be run, just remove the SD card), I make it run before S45tapsvr.sh , then make tapsvr to use /tmp/vroot/dev/mux2 instead of /dev/mux2 .

It doesn't sound as you are that much of a newbie after all . You seem to have the right idea. If this works, someone can later dig into the nastiness of ptrace syscalls to actually change the device connection of the running tapisrv instead, so that your program can be run even without changing the firmware default startup. But the way you describe is an excellent start.

As I know, there is a module called mux_cli. If /dev/mux2 is the interface for mux_cli and user space apps, it regards to not only sms but also phone call and GPRS.

I don't think it makes sense to have more than one process connected to one and the same device node (but I might be wrong). Look above just how much trouble mudassar had when his process was "fighting" with tapisrv for having the currect select call.

So, while there may be more things being done on /dev/mux2 than SMS, I think tapisrv is the only process that reads from it. So I think that if you just pass on everything that does not look as an sms you should be fine. Is there something that makes you think otherwise?