+++ This bug was initially created as a clone of Bug #171405 +++ Description of problem: The netdump-server is running on a machine with an eth card that has a few IP addresses, all but one of which are assigned via interface aliases. All these IP addresses are on the same logical subnet (vlan). The netdump clients all point to an IP that is on one of the IPs that is associated with and interface alias. I found through network sniffing on the server side that the netdump client sends its request to IP A, and while the server *does* receive the request and answer back, it answers from the main non-aliased IP B. Talking to A and hearing back from B apparently doesn't fly with the netdumping client. When I change the client to point at IP B... it works just fine. From my understanding of it, the netdump-server would in fact answer back to the client from an aliased IP A if it was bound specifically to that IP. Is there a way to get the netdump-server to bind to a specific IP address? This is an option for most other network services... but I don't see any mention of that in the netdump-server man page or init script. Version-Release number of selected component (if applicable): netdump-0.7.7-2 netdump-server-0.7.7-2 How reproducible: 100% Steps to Reproduce: 1. Configure a netdump server with multiple addresses via ethernet aliases. All addresses should be on the same subnet. 2. Configure the netdump client to dump to one of the aliased addresses on the server. 3. Initiate a netdump. The return packets will come from a different IP address, and so the netdump client will discard them. Actual results: The netdump server will timeout when trying to handshake with the client. Expected results: A full netdump should be taken. Additional info: This was originally discussed in bz #145476. This bugzilla was created due to confusion in that bugzilla. Too many issues were being debugged. -- Additional comment from tgraf on 2006-01-24 10:18 EST -- Fix commited in version 0.7.16-1
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
*** Bug 185197 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0492.html