Inline... IP addresses hidden to protect the guilty/innocent. On 7/15/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
[snip] > > 2) the IP and MAC address of the target server > > eth0 Link encap:Ethernet HWaddr 00:30:48:75:72:92 > inet addr:xxx.xxx.0.139 Bcast:xxx.xxx.0.255 Mask: > 255.255.255.0 > > The pcap was captured on that machine. Ok destination MAC/IP match which is good. Assuming the packet is being sent on the same ethernet broadcast it should be delivered by any switch, hub etc. > > 3) the IP and MAC address of the client > > I also have tried to replay it from > > eth0 Link encap:Ethernet HWaddr 00:30:48:75:2C:14 > inet addr:xxx.xxx.0.138 Bcast:xxx.xxx.0.255 Mask: > 255.255.255.0 So this host, is connected to the target over a switch? Unless the switch is doing something funny this should work. > but the packet originated from > > eth1 Link encap:Ethernet HWaddr 00:1C:42:28:F8:E9 > inet addr:yyy.yyy.55.5 Bcast:yyy.yyy.55.255 Mask: > 255.255.255.0 > > and got NATed and routed to the target server. Shouldn't cause a problem here. > > 4) Are the two boxes connected via a switch, hub, bridge, cross over > > cable or ??? > > Need to double check with OPS but I am 99.9% sure they are connected > via switch Hmmm... I wonder if that switch is a bit too intelligent for it's own good... some PIX blade or something. I would try a cross over cable between the two hosts and see what happens then. > >>> 2) Replay the traffic on the same host, but from a different > >>> interface > >>> (eth1 for example) > >> > >> Hmm... does that interface need to be on the same subnet? ...because > >> replaying on either the 172.x, the 10.x or lo interfaces doesn't help > >> either. > > > > Generally speaking, yes, both interfaces need to be on the same > > subnet/broadcast domain. The important thing isn't the IP addresses, > > but rather that they're on the same broadcast domain (assuming > > ethernet). > > Hm... I've test with > > ifconfig eth0:0 xxx.xxx.0.150 netmask 255.255.255.0 up ; tcpreplay - > i eth0:0 -v one_beacon.pcap ; ifconfig eth0:0 down > ifconfig eth1:1 xxx.xxx.0.150 netmask 255.255.255.0 up ; tcpreplay - > i eth1:1 -v one_beacon.pcap ; ifconfig eth1:1 down Yeah, using aliased interfaces won't help here, because the packet is leaving the physical interface and will not be picked up by the hosts IP stack since the packet is going the wrong direction. > but neither resulted in a receive on the server (who is listening on > 0.0.0.0:33333 on the same machine). > NOTE: I slightly changed IP addresses and port number for the post on > the mailing list > > Server is running Linux version 2.6.17-11-server (Ubuntu > 4.1.1-13ubuntu5) > > > Otherwise you'll need to go through a router or other > > device which will require the destination MAC address to change. > > So that should not be required. Honestly, I don't see anything wrong with your setup as you've described it. I can only think that something is funny with that switch and you should try to remove it as a variable. BTW, what version of tcpreplay are you using? -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
