Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 231937

Summary: vmware-server retains old network address
Product: Gentoo Linux Reporter: Peter Humphrey <peter>
Component: Current packagesAssignee: Gentoo VMWare Bug Squashers [disabled] <vmware+disabled>
Severity: normal CC: jer
Priority: High    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Package list:
Runtime testing required: ---

Description Peter Humphrey 2008-07-16 09:31:48 UTC
I've changed the addresses of my network interfaces, but vmware-server still tries to use the old ones. It's running on an amd64 box with a bridged connection on eth0 and a host-only connection on vmnet1.

I recently changed the addresses of both these connections. The box used to have address and it now has I used to let vmware-config set the host-only connection address for itself but now I give it

Now when vmware-server is running it disrupts the real network in several ways: another machine can't get a connection to the rsync server which runs on the vmware-server box; I can't ping that box from the vmware-server; the Windows XP client running under vmware-server sometimes reports an address clash with other machines on its network; my firewall box reports streams of martions trying to addres, port 3128.

I've grepped -r /etc for '192\.168\.129' and found nothing, and the same in /opt/vmware. I've run the network control-panel applet in Win XP and confirmed the correct addresses, and I've run the Win XP registry editor to search for 192.168.129. Nothing turns up.

If I shut vmware-server down, the real network comes back to life. If I rerun vmware-config to omit the host-only network, the real network functions but I still get the martians reported by the firewall.

What else can I try?

Reproducible: Always

$ emerge --info
Portage (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r6 x86_64)
System uname: 2.6.25-gentoo-r6 x86_64 AMD Sempron(tm) Processor 2800+
Timestamp of tree: Wed, 16 Jul 2008 08:16:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python:     2.4.4-r13
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-devel/autoconf:  2.13, 2.61-r2
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
CFLAGS="-O2 -march=k8 -pipe"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/init.d /etc/pam.d /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -march=k8 -pipe"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
FEATURES="buildpkg ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="X amd64 apache2 bash-completion berkdb bindist bzip2 cdr cgi cli cracklib crypt cups curl dbus dri dvd dvdr fam firefox fortran gdbm gphoto2 gpm gtk iconv imap innodb ipv6 jpeg jpeg2k kde libwww lm_sensors logitech-mouse logrotate maildir midi mudflap mysqli ncurses nls nptl nptlonly nsplugins openmp pam pcre perl png ppds pppd python readline reflection sasl sdl session spl ssl symlink tcpd tiff unicode usb userlocales vhosts via xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="fuji" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="via"
Comment 1 Mike Auty (RETIRED) gentoo-dev 2008-07-17 08:44:27 UTC
Hiya Peter,

First off, I'd suggest dealing with one network adapter at a time.  Start up the vmware machine and then disable one or the other of the networks and tests how it works.  You haven't quite provided enough information to figure everything out.  You said you changed the address of both connections, but you can't change the address of a bridge, because it's a bridge.  Each individual machine making use of the bridge will need its IP address changing, or the DHCP server handing out address will need to be reconfigured.  Which method are your client machines using on the bridged interface to get an IP address?  Static or dynamic? 

After you've verified that the bridged connection is only doing exactly what it's supposed to, swap over to the host-only connection, and again test it in isolation.  Put wireshark on both the client and host, and see what traffic the client's seeing, what traffic the host's seeing, and whether your 192.168.129.x packets are originating on the client or not.  You said the windows boxes IP was correct, so how is this likely to be a vmware issue?  If the client thinks it has the correct address, the server thinks it has the correct address, and there's no NATing going on, vmware isn't going to touch any of the packets...

I'm really not convinced this is a package issue, but more of a configuration issue.  Given how much complexity is going on (your network's, the vmware client's setup, the host machine's setup and the vmware-server config itself) I'm fully expecting this to be configuration related and not code related.  If you're just asking for advice, you'd be best off consulting on the Gentoo forums, the gentoo-user mailing list, on IRC, or on the Vmware Technology Network (VMTN) forums, rather than filing a full fledged bug about the package itself.  Sorry I can't be of more help, but bugzilla is not a user support resource...

Please let me know how you get on, but I'm going to mark this bug as NEEDINFO, meaning I'll need you to either track down exactly where the failing in vmware server is or it's going to stay closed I'm afraid...  5:(