RESMGR_FLAG_BEFORE with ENOENT in socket trapper

Help, me!
Please, explain me following situation.

I have qnx6.1.

If I return ENOENT from open handler then in further all my others handlers will not get
control.
But all will works OK!
But without my handlers !!!

Else – if I return iofunc_open_default() then I need actual processing in my handlers.
I.e. if I return ENOENT from its – client wiill get just ENOENT !!!

How can I will not actual processing in my handlers with condition of normal work of all
others IO requests ?
I want to observe only, now !

I see that observation influences on object which is observated in this sample :slight_smile:
How do to avoid this situation ?

1st I see it should return ENOENT from open handler but what should do in others
handlers ?

Vasili

Here is an example that is somewhat simpler then your situation. Lets
say we wanted to “sniff” the data coming in and going out of a serial
device…we could then…

RealFd = open( “/dev/ser1”, O_RDWR );
resmgr_attach( …, “/dev/ser1”, … );

Now - when a write happens to our new /dev/ser1 we can look at the data
and then forward it on to the real device using write() on the FD we
obtained before we registered the path. If you are “really” tricky you
can just turn the operation into a MsgSend() directly.

chris


Help, me!
Please, explain me following situation.

I have qnx6.1.

If I return ENOENT from open handler then in further all my others handlers wi
ll not get
control.
But all will works OK!
But without my handlers !!!

Else – if I return iofunc_open_default() then I need actual processing in my ha
ndlers.
I.e. if I return ENOENT from its – client wiill get just ENOENT !!!

How can I will not actual processing in my handlers with condition of normal wor
k of all
others IO requests ?
I want to observe only, now !

I see that observation influences on object which is observated in this sample :
)
How do to avoid this situation ?

1st I see it should return ENOENT from open handler but what should do in othe
rs
handlers ?

Vasili
\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Here is an example that is somewhat simpler then your situation. Lets
say we wanted to “sniff” the data coming in and going out of a serial
device…we could then…

RealFd = open( “/dev/ser1”, O_RDWR );
resmgr_attach( …, “/dev/ser1”, … );

Now - when a write happens to our new /dev/ser1 we can look at the data
and then forward it on to the real device using write() on the FD we
obtained before we registered the path.

It is another case.
In my case, “open” on “/dev/socket/2” always calls AFTER “resmgr_attach”.
And those “open” could be called multiple times by many different applications.


If you are “really” tricky you
can just turn the operation into a MsgSend() directly.

I’m not “really” tricky :frowning:

What are any ideas yet ?

Vasilii

vasa <vv40in@mail.ru> wrote:

Here is an example that is somewhat simpler then your situation. Lets
say we wanted to “sniff” the data coming in and going out of a serial
device…we could then…

RealFd = open( “/dev/ser1”, O_RDWR );
resmgr_attach( …, “/dev/ser1”, … );

Now - when a write happens to our new /dev/ser1 we can look at the data
and then forward it on to the real device using write() on the FD we
obtained before we registered the path.

It is another case.
In my case, “open” on “/dev/socket/2” always calls AFTER “resmgr_attach”.
And those “open” could be called multiple times by many different applications.

You didn’t really get it. The “RealFd” is in your server program who
did the “resmgr_attach”. That is (like I explained in email), before
you “hijack” the orignal service, keep an connection to it. Thus,
you can always use the “RealFd” to talk to orignal service in feature.

In fact, since your “resmgr_attach()” don’t have a “FLAG_SELF”, you
also can do the “open(”/dev/ser1")" (or socket(AF_INET, t, p)) in
your open handler.

-xtang

vasa <vv40in@mail.ru> wrote:

Here is an example that is somewhat simpler then your situation. Lets
say we wanted to “sniff” the data coming in and going out of a serial
device…we could then…

RealFd = open( “/dev/ser1”, O_RDWR );
resmgr_attach( …, “/dev/ser1”, … );

Now - when a write happens to our new /dev/ser1 we can look at the data
and then forward it on to the real device using write() on the FD we
obtained before we registered the path.

It is another case.
In my case, “open” on “/dev/socket/2” always calls AFTER “resmgr_attach”.
And those “open” could be called multiple times by many different applications.

In this case you are going to have to preform an open() on /dev/socket/2,
and then get the “raw” Connection information using ConnectServerInfo()
and then you can make new connections using this information in the
same was the open() library call does it. Getting scary huh?


chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Xiaodan Tang <xtang@qnx.com> wrote:

In fact, since your “resmgr_attach()” don’t have a “FLAG_SELF”, you
also can do the “open(”/dev/ser1")" (or socket(AF_INET, t, p)) in
your open handler.

Oohhhh! That is even better then my ConnectServerInfo() but not nearly
as cool sounding! :slight_smile:

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

It is another case.
In my case, “open” on “/dev/socket/2” always calls AFTER “resmgr_attach”.
And those “open” could be called multiple times by many different applications.

You didn’t really get it. The “RealFd” is in your server program who
did the “resmgr_attach”. That is (like I explained in email), before
you “hijack” the orignal service, keep an connection to it. Thus,
you can always use the “RealFd” to talk to orignal service in feature.

In fact, since your “resmgr_attach()” don’t have a “FLAG_SELF”, you
also can do the “open(”/dev/ser1")" (or socket(AF_INET, t, p)) in
your open handler.

I checked that. It is works but it is too difficult.
There should open socket for EVERY “open” handler call !!!
But I need to handle only particular socket, it will register itself
by “ioctl” call to my trapper. It will be AFTER it call “open”.

Q1: Am I doomed to handler all socket calls ? (Now, I think it is rhetorical answer :slight_smile:
It is terribly !!!

Q2: How do to handle recv/recvfrom and like those (as MsgSend-implemented) ? How can I
access to its arguments ESPECIALY ?

In this case you are going to have to preform an open() on /dev/socket/2,
and then get the “raw” Connection information using ConnectServerInfo()
and then you can make new connections using this information in the
same was the open() library call does it. Getting scary huh?

YES,

Vasilii

Say me, please,

Even so, Does there exist possibility to know the NEXT resmgr ???
It would be a good solution, IMHO.

Vasilii

Now I realy see that method to trap socket IO operations is too difficult to realize
configurable tcpip stack.

  1. It is needed to open new socket for EVERY socket call (when we yet dont know about
    socket – we should to process it or no).
  2. it is doomed to process (REALLY!) every (EVERY!) i/o operation on EVERY opened socket.
  3. processing sockets should be opened AFTER interceptor loaded.
  4. after interceptor will be shutdowned – ALL(!) opened in that period sockets will be
    shutdowned.

If I wrong something or somebody has another idea – say me, please.

Vasilii

vasa <vv40in@mail.ru> wrote:

In this case you are going to have to preform an open() on /dev/socket/2,
and then get the “raw” Connection information using ConnectServerInfo()
and then you can make new connections using this information in the
same was the open() library call does it. Getting scary huh?

YES,

:slight_smile: If you are only interested in handling a specific socket (and you know
the port and IP address information of the connection), why not just insert
an ip_ip filter into io-net? Then your filter can setup a new/unique
interface in /dev/socket (say /dev/socket/myfilter) and you can just
send the devclt()'s with port/ip information to that location.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

vasa <vv40in@mail.ru> wrote:

Now I realy see that method to trap socket IO operations is too difficult to realize
configurable tcpip stack.

Of cause. You want to “intercept socket call”. The first question we
asked is “why”? :slight_smile:

All the discussion here is syaing “it is doable”, nobody said it’s
easy. On most popular unix system , what you want to do is “impossiable”.
A socket call is a system trap (kernel call) on those system, and you
can’t do anything except recompile the kernel.

  1. It is needed to open new socket for EVERY socket call (when we yet dont know about
    socket – we should to process it or no).
  2. it is doomed to process (REALLY!) every (EVERY!) i/o operation on EVERY opened socket.
  3. processing sockets should be opened AFTER interceptor loaded.
  4. after interceptor will be shutdowned – ALL(!) opened in that period sockets will be
    shutdowned.

All these are true. Because you want to “intercept”, right?
A client is talking to a server, you want to “intercpet” them,
that is saying, you want to get into their way, make the client
talk to you, and you (represent the client) talk to the server.
Then you have to handle “everything” the client may say.

“Intercept socket call” is a strange concept, you are probably
wrong in first place. If you can explain “what” do you want to
intercept, "what " do you wan to achive, we might do better.

Bottom line, you can always compile your own libsocket.so, and
make it do special thing in each API.

-xtang

:slight_smile: > If you are only interested in handling a specific socket (and you know
the port and IP address information of the connection), why not just insert
an ip_ip filter into io-net? Then your filter can setup a new/unique
interface in /dev/socket (say /dev/socket/myfilter) and you can just
send the devclt()'s with port/ip information to that location.

I thought about socket calls interception because I need to process FULL packet (not
fragmented but ip_ip or like that filters dialing with fragmented packets in both
directions – up & down).
This, no new interfaces or/and new domains could be added. All should be transparent for
socket owner process as it is works in raw native environment.
And it is too difficult to process intercepting blocking calls such as read
and:

  1. after interceptor will be shutdowned – ALL(!) opened in that period sockets will
    be
    shutdowned !!!

May be, as Xtang advised, it is need to think about libsocket.so recompilation.
It is possible, the better solution, I think.

Vasilii

On most popular unix system , what you want to do is “impossiable”.

Say me on which systems it is possible if You know, please.

“Intercept socket call” is a strange concept, you are probably
wrong in first place.

I’m agree.

If you can explain “what” do you want to
intercept, "what " do you wan to achive, we might do better.

I explained that – it is configurable tcpip stack.
It should be possibility to add modules to change packet processing should be added at
runtime,
but (!) they should process unragmented packets – i.e. they should not be ip_ip or like
this filters !

Bottom line, you can always compile your own libsocket.so, and
make it do special thing in each API.

I need to think about it. It is possible, the better solution.

Vasilii