Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have a vmware machine that runs RHEL5 and it has 2 NICs eth0 and eth1. When I clone (copy) this machine, my NICs are changed as:
eth0 becomes eth2
eth1 becomes eth3
How should I do to recover all NICs back to eth0 and eth1?
This is common when you clone a virtual machine. udev renames your interfaces while booting. You can edit the udev rules in file /etc/udev/rules.d/70-persistent-net.rules. It is better to read the vmware kbase
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1032790
In modern Linux systems kernel names for devices are often corrected by udev ( look for /etc/udev/rules.d/70-persistent-net.rules ) or similar.
When system boots up first time, HW addresses of network cards are saved to ensure e.g. if they will be replaced on motherboard or new physical interface added, previously existing interfaces will still have same "ethX" system name. This way network card with aa:aa:bb:cc.. will always be "eth2" in system, for example even if kernel previously was recognizing it as eth1 and now it recognizes it as eth4 due to some change of physical configuration of hardware.
When you create a clone of virtual system (obviously including all files on all its filesystems), pseudo-physical devices get new HW address, while HW addresses they had in originating system are still reserved for eth0 and eth1 - that is why when kernel of clones detect these cards, it assigns them eth2 and eth3 names.
Some VM environments have options of cloning, which allows choosing if clone should keep previously used HW addresses, or new shall be generated/assigned. Also, most VM environments allow arbitral setting of HW addresses of virtual network cards.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I wanted to use my android phone as a display for my Raspberry Pi 4B, so I searched the internet, found an instruction and copied the code into my Pi, I was connected to (via SSH). This is the code I put into /etc/network/interfaces:
iface usb0 inet static
address 192.168.42.42
netmask 255.255.255.0
network 192.168.42.0
broadcast 192.168.42.255
This sets the IP to a static one (192.168.42.42).
I rebooted and tried to SSH with IP 192.168.42.42, because I thought, this was the new IP for the Raspberry Pi.
Long story short, it doesn't work. I also tried some other IP's, I cant find the IP in NUTTY or with nmap.
How can I connect to my PI now? (I don't have a monitor or a crossover LAN cable)
I'm using an older MacBook Pro with Linux Mint 19
Where I got the code from: https://joshuawoehlke.com/android-raspberry-pi-display-over-usb/
You could take the SD card out of the Pi and put it in your Mac/Linux machine and correct/remove the /etc/network/interfaces file from the SD card.
Or, you could go to the SD card's /boot partition and touch ssh in that directory so that sshd starts and also create in that same directory a wpa_supplicant file to match a temporary WiFi hotspot you create on your phone or Mac. Then you can ssh into it over WiFi and whatever you want.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'm trying to set up a group of VM's using MAAS with vagrant and virtualbox using a host only network shared between the VMs. I'm trying to get the node VMs to use PXE to install the operating system. I've got the node VMs to start PXE booting by setting up DHCP on the controller VM and forcing the node VM to boot from the second nic. The installation gets part of the way through before stopping when cloud-init tries to download the config. My Vagrant file is at https://gist.github.com/pj/3db0fe2e87cf35d4f6ffb37a5b5b8bb6.
As far as I can tell, MAAS is delivering the address to cloud-init through the cloud-config-url boot parameter. From looking at the output when the PXE node tries to boot I can see that the address being delivered contains the ip address of the NAT nic that Vagrant automatically creates for VMs, not the ip address of the host-only network which was used for DHCP and to deliver the PXE boot files.
Is there a way to change the ip of the cloud-config-url boot parameter? In the MAAS source it seems like this is derived from some part of the RackController config, but I couldn't trace where it was set from.
Okay figured it out, I needed to set the url for the rack and region controller using the following commands:
sudo maas-region local_config_set --maas-url="http://192.168.50.2:5240/MAAS"
sudo maas-rack config --region-url="http://192.168.50.2:5240/MAAS"
In our setup, instead of forcing slave nodes (the one that PXE-booted and managed by MAAS controler) to use host-network IP as shown above, we have made the MAAS controller a router for its managing subnet. This is a more robust configuration and closer to an actual environment.
From what we have seen, these nodes, once PXE-booted, need internet access in order to load more packages on top of OS. Otherwise, they can be in an intermediate state and never finish "deploy" until a timeout error.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
when I put this in the terminal
ifconfig eth0 69.69.69.69
the ip address in the terminal change but in the user interface not, I mean
initial state
my ip is 192.168.10.2
then a put in the terminal
ifconfig eth0 69.69.69.69
and this happens
terminal
properties
As we can see the properties didn't change.
what can I do for change that properties using the terminal or a bash?
You are probably using a Linux distribution that uses the NetworkManager daemon, and during installation it decided that eth0 should be configured via DHCP. So every time you manually setup its IP not using it (from a terminal in your case), NetworkManager will set it up again without noticing you within a few seconds or minutes.
To check if you have indeed NetworkManager running and managing eth0 setup, issue:
ps aux | grep -i networkmanager
If it is indeed running, look for more info about it, from Ubuntu for instance:
https://help.ubuntu.com/community/NetworkManager
...and then google around for "network manager manual setup ip".
PS:
I hate NetworkManager with a deep passion, gave up using it years ago and always uninstall it, managing my interfaces manually and/or the good old /etc/network/interfaces way. Noticeably (in my case) it can be a pure nuisance when multihoming and changing the interfaceS setup frequently. So if this is indeed your problem (90% sure) I can't help you much more with it. NetworkManager is good at managing one interface at a time, with one configuration (ex static or DHCP) for each interface. This satisfy 95% of user cases. But not mine.
i have try this in my computer and i have success
ifconfig eth0 192.168.218.110
if you want to chang the /etc/sysconfig/network-scripts/ifcfg-eth0 to chang the ip.
you can use vim edit chang thhis line:IPADDR=192.168.218.111
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am trying to setup openvpn on a server so that I have 2 different tap interfaces (tap0 and tap1) and then a bridge connecting those interfaces. The idea is that a client on tap0 will be able to talk to a client on tap1 and vice-versa.
There is no physical NIC involved in the bridge and the Bridge interface is setup with no ip/netmask/broadcast.
I am able to ping between the 2 when they are both connected however I see no traffic when trying to tcpdump the bridge interface.
I am a bit confused on some things:
Do I need to have an ip configured on the bridge interface at all? I don't quite see the reason for it as all it will do is to make to virtual interfaces talk to each other
Is the fact that the bridge interface does not have an assigned ip/netmask/broadcast the reason I am not able to see the ping traffic on the bridge interface when tcpdumping that interface?
If the answer to number 2 is Yes, I assume that it is not either possible to use iptables to block/allow traffic on that interface, correct? If so is there any other way to accomplish what one would do with iptables on an interface like that?
I guess this wasn't the proper place to put this question but I thought I'd put an update anyway to close the issue.
Turns out that you do not need an assigned ip address on the bridge and it is possible to tcpdump. I happened to be working in containers which made the traffic go outside the vpn when pinging.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
All firewalls are turned off.
I have 3 Fedora 20 machines and 1 Windows 7 machine on the same 172.x.x.x LAN.
They all have static IP addresses and same subnet. (255.255.255.0)
The Fedora machines can all ping each other.
The Windows 7 machine can ping all 3 Fedora machines.
The Fedora machines, however, cannot ping the Windows 7 machine. I get the response: Destination Host Unreachable.
I ran Wireshark on the Windows machine. ICMP messages show up when pinging from Windows to Fedora, but not the other way around.
To further complicate matters, all machines also have a second network adapter hooked up to a second 10.x.x.x network. On THIS network, all machines CAN ping each other, Windows to Fedora AND Fedora to Windows. It's just the 172.x network where the Fedora machines cannot ping the Windows machine.
I know
there are tons of posts out there already for "cannot ping" issues,
but I haven't been able to find anything that helps with this
specific scenario. Or when I do, it turns out to have been a firewall
issue, and there is no firewall running on these machines.
Any thoughts?
Thank you.
On the Windows machines, make sure that the Network Discovery protocol is turned on. You can doublecheck this by clicking on "Network" in Explorer, and there may be a prompt at the top of the Explorer window that asks you to turn it on. The reason it may work on the 10.x.x.x network is because it may recognize that network as a Home or Work network, but the 172.x.x.x network as a public network. The settings are separate for each type of network.
When pinging from Fedora to Windows on the 172.x.x.x network, it's possible that the source IP of the ping packet is getting set to the IP address on the 10.x.x.x network. This may cause the packet to get dropped immediately by Windows since a packet arrived on the 172.x.x.x interface with a source IP that belongs to the subnet on another interface. This can be easily confirmed by tcpdump/wireshark on Fedora.
======== EDIT ========
So we have confirmed that when Fedora (172.124.16.128) pings Windows (172.124.16.39), the destination MAC address is set to 00:00:00:00:00:00, which is incorrect. The target MAC should be the MAC address of the network interface on Windows that has the IP address of 172.124.16.39 configured on it.
The process of resolving IP to MAC addresses is done by ARP (Address Resolution Protocol), and should happen automatically in the background. To debug why the MAC address isn't getting resolved properly, please clear all ARP cache on Fedora (Google how to clear ARP cache on Linux), start capturing packets, then see what happens with the ARP packets. If you have trouble understanding the packets, you can post them here, and I will take a look.