Bug 455265

Summary:	netdump uses hard-coded remote port for server
Product:	[Fedora] Fedora EPEL	Reporter:	Bryn M. Reeves <bmr>
Component:	netdump-server	Assignee:	Neil Horman <nhorman>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	el5	CC:	mastahnke, tao, tremble
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	ActualBug
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-09-22 08:17:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bryn M. Reeves 2008-07-14 14:49:52 UTC

+++ This bug was initially created as a clone of Bug #454703 +++

Description of problem:
The netdump server uses a hard coded remote port when replying to netdump clients:

netdumpclient.c:
netdump_client_send_reboot ()
[...]
  addr.sin_port = htons(NETDUMP_PORT);
  addr.sin_addr.s_addr = htonl(reboot->ip);

netdump_client_send_request ()
[...]
  addr.sin_port = htons(NETDUMP_PORT);
  addr.sin_addr.s_addr = htonl(client->ip);

This prevents the server communicating with clients that have defined a
non-default LOCALPORT in /etc/sysconfig/netdump.

Version-Release number of selected component (if applicable):
0.7.16-14.EL

How reproducible:
100%

Steps to Reproduce:
1. Configure a netdump client with LOCALPORT!=6666
2. Force a crash on the client

Actual results:
Netdump server replies to port 6666, netdump handshake fails

Expected results:
Netdump server replies to the client's LOCALPORT

Additional info:

-- Additional comment from bmr on 2008-07-09 16:18 EST --
Created an attachment (id=311416)
use the client's local port when replying

-- Additional comment from nhorman on 2008-07-11 15:45 EST --
fixed in -21.el5, thanks!

Comment 1 Mark Chappell 2010-09-22 08:17:58 UTC

netdump-server-0.7.16-22.el5 is in EPEL-5 now and claims to fix this issue so I'm closing off this bug.  Feel free to reopen the bug if you're still having problems.