OSDev.org

I have a couple of big issues with the way my OS is handling networks.
first off, my OS is a network-enabled system that really has no other purpose than to be a fast switch at the moment.

I have two NICs installed and I am trying to get them to seem invisible to the network by using a pass-through feature. look below for an explanation (yay, text diagrams!) =)

____ _____
| | OS | |
node A | |------------------|~~~~~|----------------------- | | node B
|__| |___|

what is happening is that, node A can talk to node B, but node B cant respond or send anything at all to node A. I would like my OS to just pass along all ofthe packets blindly through the other NIC and out to the recieving node. the problem I am having, is that when node B recieves an ARP from node A, it cant respond because technically it can not see node A because of my OS in the way, and it wont send the packet to my OS because it is not the proper recepient.

how about spoofing the MAC addresses, so that NIC 1 has the mac of host B and NIC 2 has the mac of host A

wow, that drawing came out horrible haha.
now say that there is an entire cluster on each side of the OS machine. That method would not work because in a corporate enviroment that would take alot of memory to create a massive network-wide arp table. can you think of a way to incorporate 'switch-ness' without comprimising speed by using a directory listing of ip/mac addresses.

I could barely understand you.. but it sounds like you're just trying to create a bridge...

OpenBSD for instance has great routing capabilities, often I'm in a situation where bridging is handy.. This initialized the xl0 interface on network 1. This initialized the xl1 interface on network 2. Now traffic flows freely between network 1 and 2... with MAC caching enabled..

Perhaps this is what you were talking about?

wow I guess I am not as familar with the unix shell commands as i thought i was haha. xl0 and xl1 are foreign to me. Bridge mode is deffinately what I would like to achieve. Any suggestions on how to implement that?

or enabling promiscuous mode?

btw im running two RTL8139D's.

You could try looking at the source code... OpenBSD is open source after all..

Did you get the proper datasheet for your device? http://www.realtek.com.tw/products/prod ... &ProdID=18

As for xl0 and xl1, Apologies.. under OpenBSD they represent my 3com network cards...

whats happening now is that host A can talk to host B but when host B tries to respond, it doesnt even make it too my OS machine in the middle, which leads me to believe that it doesnt know where to physically send the packet. btw, I am leaving the packets un-altered and just recieving on one nic and sending it out the other one.

also, a friend was telling me about using crossover cables. will I need to use them in this case or will regular-wired cat5 work? if need be I can re-crimp some cat5 with the switched cables quick enough.

I do not understand how host B can not respond to the ARP packet. It should respond, and switch the source and destination MAC address. The network devices on your switch should be in promiscuous mode so that they will not just ignore frames going to other destinations them selves.

If they are not in promiscuous mode then it will appear from the operating systems point of view that the packet is never being sent, but my question is how did you see the original ARP packet to begin with? The only answer I can think of is that one of the cards is not in promiscuous mode?

As a switch, IIRC, all you are going to be doing is:

1. Is the destination address of this frame registered on any of my ports?
2. Yes, Then which one and copy packet and retransmit there.
3. No, Then broadcast to all ports.
4. Is the source address of this frame registered on the port it came from?
5. No, Then register it.
6. Yes, then it is fine.

You should try using a packet sniffer on host B to see what it really does send!

Thanks for that breakdown of a switch. =)

Also I have a question about promiscuous mode. If I set the AcceptAllPhysical register on the eth card, do I need to set the other bits (acceptmulticast,acceptbroadcast,acceptphys) bits as well or just that one bit to put it in promisc mode?

Hmm.. I am not sure about that. My actual experience does not reach that far. But, I can try to help you by saying that judging by bits it appears that enabling them all should cause no problems until you can further decide exactly which ones you need enabled.

Maybe, someone else here could shred some light on that.