blind packet passthrough

01000101 · Post by **01000101** » Thu Oct 11, 2007 11:10 am

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.

Combuster · Post by **Combuster** » Thu Oct 11, 2007 2:52 pm

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

01000101 · Post by **01000101** » Fri Oct 12, 2007 7:21 pm

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.

Brynet-Inc · Post by **Brynet-Inc** » Fri Oct 12, 2007 10:38 pm

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..

Code: Select all

ifconfig xl0 up

This initialized the xl0 interface on network 1.

Code: Select all

ifconfig xl1 up

This initialized the xl1 interface on network 2.

Code: Select all

brconfig bridge0 add xl0 add xl1 maxaddr 254 up

Now traffic flows freely between network 1 and 2... with MAC caching enabled..

Perhaps this is what you were talking about?

01000101 · Post by **01000101** » Sat Oct 13, 2007 2:39 pm

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.

Brynet-Inc · Post by **Brynet-Inc** » Sat Oct 13, 2007 5:36 pm

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...

01000101 · Post by **01000101** » Tue Oct 16, 2007 9:13 pm

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.

Kevin McGuire · Post by **Kevin McGuire** » Wed Oct 17, 2007 3:12 am

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:

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

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

01000101 · Post by **01000101** » Thu Oct 18, 2007 11:23 am

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?

Kevin McGuire · Post by **Kevin McGuire** » Thu Oct 18, 2007 1:10 pm

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.