Adding new Network Service

[argn...@gmail.com]

I'm trying to add my own network service to vxWorks so that my raw
ethernet protocol (0x6100) can be read and accepted. I've added the
service and am able to send and receive on 0x6100. The problem that I
am seeing is that after muxTkBind is called, my previously functioning
IP does not work anymore.
The incoming IP packets (protocol 0x800) and the ARP packets (protocol
0x806) actually go into my service's receive function. From there, I
check the type and return False if it is not 0x6100, so that IP can
accept the packet. I see from ipshowStat that it gets to IP, but IP
just seems to ignore it. I've also printed out the data in my
service's receive method and it shows the whole IP packet (without the
ethernet header, but with the ethernet checksum).
My service had an attach routine which performs the muxTkBind. I've
also added the error, shutdown, and restart routines. Again, the
service seems to work fine if it attaches after IP attaches, but IP
does not work. The opposite case, if IP attaches last, IP seems to
work fine.
Does anyone have any thoughts on this? The driver is an END driver and
this is vxWorks 5.4.
Thanks

[raj]

You shouldn't be receiving packets other than type 0x6100 unless you
set the type in muxTxBind() to MUX_PROTO_SNARF or MUX_PROTO_PROMISC. If
that's what your doing try setting it to 0x6100. Yes, you should be
able to look at all incoming packets and only pick off the ones your
interested in but I've had trouble with that before too although I was
using muxBind() not muxTkBind(). Oh, another thing your supposed to
return ERROR (-1) from the receive function if you don't want to
process it not False (0) which is that same thing as OK which would
mean you have consumed it.

[argn...@gmail.com]

Thanks for the information. I don't understand why I am seeing all
packets. I am specifically setting it to receive only 0x6100. Do I
need to call muxLibInit() or muxTkLibInit() before I call muxTkBind?
The VxWorks Network Protocol Toolkit book says to return FALSE. Is
that an error in the book, then? I'm going to try this out and see if
other layers can now see it.
One more thing, I see that Wind Debug Agent is running a SNARF protocol
when I do a muxShow. Is there a way to prevent this but still be able
to use the Tornado debug shell?

[raj]

You're right about the return value. It should should be TRUE to
consume the packet and FALSE to let it go - my mistake. If you're still
having trouble you might try using muxBind() instead. It seems to be a
little easier to use. At least I've had good luck with it. I've never
had to call muxLibInit() myself. I think it gets called earlier in init
like this usrRoot() -> usrNetworkInit() -> usrMuxLibInit() ->
muxLibInit() -> muxTkLibInit(). Don't know much about the debug shell
sorry.

[Dr. Diags]

Argnbrit,

<argn...@gmail.com> wrote in message
news:1114799544.6...@g14g2000cwa.googlegroups.com...

You could configure the WDB agent to use the following in your config.h if
building from the command
line:

#define WDB_COMM_NETWORK 0 /* vxWorks network - task mode */

so in the config.h, do this:

#undef WDB_COMM_TYPE
#define WDB_COMM_TYPE WDB_COMM_NETWORK /* default path is the network */

You lose "System level debugging". Currently you are using:

#define WDB_COMM_END 6 /* END packet device - bimodal */

If you use the project facility, go to the Network section and de-select
"System level debugging" and
change the communication method to network instead of END. In later Tornado
release, this isn't a problem as
Berkely Packet Filters are used and you can have multiple SNARF-type
attachments....

>

[argn...@gmail.com]

Ok, I will try this from the project facility. Thanks.

Regarding the muxTkBind versus muxBind, I am able to get it working
with muxBind but not muxTkBind still. I am concerned about this
because muxBind is only available to use with END drivers and not NPT
drivers. If anyone has had luck with the muxTkBind, please let me
know.