Comments below...

xcelcior wrote:
>
> greetings
> Im using cheap thread in my project and i cant quite make as desired.
>
> problem description:
> one of my modules is a transparent bridge system. (a PC with 2 NICs)
> basically, this system just throws all packets sniffed from NIC A to
> NIC B and also the other way around.
>
> so in my program i've created 2 threads and called the ct_sched()
>
> The 1st thread sniffs packets from NIC A then throws it to NIC B for
> retransmission.
>
> The 2nd thread does the same thing but the other way around NIC B to
> NIC A.
>
> All went fine until I tested it and what happended is that when a
> packet is received from NIC A thread 1 callback function is executed
> but thread 2 is also executed which should not happen since no
> packet is detected on NICB. i think it got something to do with the
> shared memory space (void * pdata) but i dont know how to use it.
>
> WELL I HOPE SOMEONE COULD HELP ME THNX

I'm not sure what you're complaining of. You say that thread 2
runs. It's supposed to. That's what the scheduler does for you --
it runs the threads repeatedly. Assuming that the two threads are
at the same priority, and that no other threads are involved, the two
threads will take turns.

(Actually you're likely to have at least one other thread running so
that it can terminate the first two. Otherwise you have an endless
loop until both threads encounter an error and call ct_exit().)

You're not referencing pData within thread_NIC1(), so I don't think your
problem has anything to do with pData.

I assume that pcap_next_ex() reads a packet from the NIC and loads its
contents into pkt_data[]. I further assume that pcap_sendpacket()
writes the contents of pkt_data[] to the specified NIC.

> source code:
> int thread_NIC1( void * pData )
> {
> //pcap_next_ex() will only return if a packet
> //is detected on a NIC

I *think* you mean that it will return a positive number only when it
detects a packet. Your logic suggests that pcap_next_ex() returns zero
if no packet is detected, and -1 if an error occurs. Any other
negative values probably should never happen, but if they do, you treat
them the same as a zero.

> //thread 2 has a callback function called thread_NIC2()and
> //identical to thread_NIC1() the only difference
> //is if((res = pcap_next_ex(g_opennic2handle, &header, &pkt_data))
> //>= 0)

If that is truly the only difference then you have a problem, because
both threads will write to the same NIC. There should also be
differences in the call to pcap_sendpacket() and in one of the
calls to printf().

> if((res = pcap_next_ex(g_opennic1handle, &header, &pkt_data)) >= 0)

I'm not familiar with the API you're using, but did you mean to
pass &pkt_data rather than pkt_data? If you pass a pointer to a
pointer where you should pass a pointer to an array, then the results
are unpredictable. If you have a prototype for pcap_next_ex() in
scope then the compiler should detect such an error -- unless the
third parameter is declared as a void *, which is assignment-compatible
with any kind of pointer.

However I suspect that pkt_data is not an array, but rather a
pointer that pcap_next_ex() overwrites so that it points directly
into the packet data. That would eliminate a layer of copying. If so,
then you're passing the right thing. It's hard for me to tell because
you didn't include the declarations of your variables.

> {
> if(res == 0)
> return CT_OKAY;
>
> for(i=0;i<12;i++)
> {
> if(pkt_data[i]!=5)
> return CT_OKAY;
>
> }

I don't know what the above loop is all about, but I'm going to
assume that it makes sense, and ignore it.

<snipped: code for logging the packet to stdout>

> pcap_sendpacket(g_opennic2handle,pkt_data,
> (int)header->caplen);
>
> return CT_OKAY;
> }
> else if(res == -1)
> {
> printf("Error reading the packets: %s\n", pcap_geterr
> (g_opennic1handle));
> return ct_exit();
> }
> else
> return CT_OKAY;
> }

In short I don't really understand what your problem is, nor can
I explain it, nor fix it. However I will suggest a use for the
pData parameter.

Declare a type like the following:

typedef struct
{
NIC_handle from_handle; /* or whatever the appropriate */
NIC_handle to_handle; /* type is... */
} NIC_route;

Before creating the threads, populate two NIC_routes with the
NIC_handles, but in the opposite order. When you create the threads,
initialize them with pointers to their respective NIC_routes.

This way you can have a single callback function that works for
both threads:

int thread_NIC{ void * pData )
{
const NIC_route * pRoute = ( NIC_route * ) pData;
ASSERT( NIC_route != NULL );

if((res = pcap_next_ex(pRoute->from_handle, &header, &pkt_data))
>= 0)
{
/* ... */

pcap_sendpacket(pRoute->to_handle, pkt_data,
(int)header->caplen);

/* ... */
}
/* else etc... */
}

This approach avoids the duplication of code, and guarantees that
each thread will behave identically, except for the direction in
which they shovel the packets. If you want to add a bridge between
two other NICS you can just add another pair of threads, instead of
another pair of functions.

I hope the above will at least give you some ideas, even if it
doesn't fix your problem.

Scott McKellar mck9@...
http://home.swbell.net/mck9/ct/