Access to Ubiquiti switch CLI to disable port

SSH to the switch

• 'telnet localhost' 
• 'en'
• config
• interface X/XX the port that you want and 'shut'
  
• end
  
• write memory
• exit
• exit

that's it 

 

 

 

“Device eth0 does not seem to be present” error when we move or clone a CentOS 6.3 virtual machine in vSphere

source link

"
When we move or clone a CentOS 6.3 Virtual machine made in vSphere5.5, and boot the machine once it is moved/cloned, we get the following error:

“Device eth0 does not seem to be present”.

This is due the fact that whenever we move or clone a Virtual machine, vSphere changes the MAC Address and CentOS renames the NIC from eth0 to eth1.  CentOS stores the network interface hardware configuration using udev.  The file is:

/etc/udev/rules.d/70-persistent-net.rules

Open this file in vi editor and delete the old entry for eth0 and edit the new entry for eth1 to eth0.
Then you need to edit the following file:

/etc/sysconfig/network-scripts/ifcfg-eth0

Record the HWADDR from the 70-persistent-net.rules configuration file and replace it with the existing HWADDR in ifcfg-eth0 configuration file.

Reboot the machine.
"

Device eth0 does not seem to be present” error when we move or clone a CentOS 6.3 virtual machine in vSphere

source link

When we move or clone a CentOS 6.3 Virtual machine made in vSphere5.5, and boot the machine once it is moved/cloned, we get the following error:
“Device eth0 does not seem to be present”.

This is due the fact that whenever we move or clone a Virtual machine, vSphere changes the MAC Address and CentOS renames the NIC from eth0 to eth1.  CentOS stores the network interface hardware configuration using udev.  The file is:
/etc/udev/rules.d/70-persistent-net.rules

Open this file in vi editor and delete the old entry for eth0 and edit the new entry for eth1 to eth0.
Then you need to edit the following file:
/etc/sysconfig/network-scripts/ifcfg-eth0

Record the HWADDR from the 70-persistent-net.rules configuration file and replace it with the existing HWADDR in ifcfg-eth0 configuration file.

Reboot the machine.

Networking Error: IP address already assigned to another adapter (1179)

sourcelink

Details

• An error message indicates that the IP already exists in the network, but no other virtual machine in the network is sharing the IP.
• On a Windows virtual machine, you see this error:
  
  The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter
  
  
• After rebooting the virtual machine, the guest operating system NIC is assigned a private IP address.
• After a physical to virtual (P2V) conversion of a machine, you cannot assign an IP address to a NIC.
• After removing and re-adding a virtual NIC, the previous device is no longer visible in Device Manager.
• The NIC is re-enumerated in the guest operating system.
• After a P2V conversion, installed devices such as a Universal Serial Bus (USB) device or ghosted device, are not connected to the computer.
• The Show Hidden Devices option in Device Manager does not display the devices.
  
  Note: To view the hidden devices, navigate to My Computer > Properties > Hardware > Device Manager > View > Show Hidden Devices.

Solution

Cause

Under certain conditions, you may see this error message from a Windows guest operating system:

The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?

In this message, XXX.XXX.XXX.XXX is the IP address you are trying to set and Name of adapter is the name of a network adapter that is present in the registry but hidden in Device Manager.

This error can occur when you change a network connection's TCP/IP configuration from DHCP to a static IP address if:

• You have upgraded VMware virtual network adapters (for example, when you migrate a virtual machine from an older to a new version of VMware software). This can also include updating the virtual machine hardware version and/or upgrading the version of VMware Tools.
• You have added and removed network adapters multiple times.

This issue occurs if a network adapter with the same IP address is in the Windows registry but is hidden in the Device Manager (My Computer > Properties > Hardware > Device Manager). This hidden adapter is called a ghosted network adapter.

• You may see this if you recently performed a P2V and the resulting virtual machine still has the physical NICs and drivers for those NICs present. These ghost NICs have the old IP address and the virtual NIC cannot be assigned the same IP address.

Using the Show hidden devices option in the Device Manager (View > Show hidden devices) does not always show the old virtual NIC (ghosted adapter) to which that IP Address is assigned.

For more information, see the Microsoft Knowledge Base article 269155.

Note: The preceding link was correct as of August 20, 2013. If you find the link is broken, provide feedback and a VMware employee will update the link.

Resolution

To resolve this issue, make the ghosted network adapter visible in the Device Manager and uninstall the ghosted network adapter from the registry:

1. Click Start > Run.
2. Type cmd and press Enter.
3. At the command prompt, run this command:
   Note: In Windows 2008 and Windows 7, open the command prompt using the Run as Administrator option.
   
   set devmgr_show_nonpresent_devices=1
   Note: If this command does not work (a possibility in Windows Server 2000 and 2003), you may need to add the parameter to Windows and set its value:
   
   
   1. Right-click the My Computer desktop icon and choose Properties.
   2. Click the Advanced tab and select Environment Variables.
   3. In the System variables section, click New.
   4. Set the Variable name to devmgr_show_nonpresent_devices and set the Variable value to 1 to enable the parameter.
   5. Click OK to add the variable to Windows.
      
4. Start the Device Manager by running this command from the same command prompt:
   
   start devmgmt.msc
   
5. Click View > Show Hidden Devices.
6. Expand the Network Adapters tree (click the plus sign next to the Network adapters entry).
7. Right-click the dimmed network adapter, then click Uninstall.
8. Once all of the grayed out NICs are uninstalled, assign the IP address to the virtual NIC.
   
   Note: To assign the IP address to the virtual NIC on the command line, run the command:
   
   netsh interface ip set address "Local Area Connection #" static IP_Address Subnet_Mask Default_Gateway
   
   For example:
   
   netsh interface ip set address "Local Area Connection 2" static 192.168.1.101 255.255.255.0 192.168.1.1
   
9. Close the Device Manager.
   
   Note: In some Windows versions, a reboot may be necessary to apply the changes.

For more information, see the Microsoft Knowledge Base article 241257.

Note: The preceding link was correct as of August 20, 2013. If you find the link is broken, provide feedback and a VMware employee will update the link.

Resolve issue using DevCon utility

Alternatively, you can also resolve this issue using the DevCon utility. This is a command-line utility that acts as an alternative to Device Manager. When you use DevCon, you can enable, utility disable, restart, update, remove, and query individual devices or groups of devices.

To resolve the issue using DevCon:

1. Download the DevCon tool from Microsoft Knowledge Base article 311272.
   
   Note: The preceding link was correct as of August 20, 2013. If you find the link is broken, provide feedback and a VMware employee will update the link.
   
2. Unpack the 32-bit or 64-bit DevCon tool binary to a local folder.
3. Click Start > Run, type cmd, and press Enter.
4. Type CD:\path_to_binaries to navigate to where the devcon.exe file is located.
5. Use this syntax to find installed network adapters:
   
   devcon findall *net*
   or
   
   devcon listclass net
   Note: In the output of the previous commands, there is a line for the ghosted network adapter that is similar to PCI\.
   
6. Run this command to remove the adapter:
   
   devcon remove @device\name
   
   For example:
   
   devcon remove "@PCI\VEN_14E4&DEV_1600&SUBSYS_01C21028&REV_02\4&378EDFA4&0&00E2"
   
   Note: IDs that include an ampersand character (&) must be enclosed in quotation marks as seen in the example.
   
7. Reboot the system and you no longer see the ghost network adapters.

Note: If you did not get the Device Instance ID or the OCI name from devcon, search for the adapter name in the registry using Find by clicking Start > Run and typing regedit. Then copy the Device Instance ID for the appropriate adapter. When you locate the device, use the command from Step 6.

For related information, see:

• Virtual NIC settings on a Windows guest are lost after a virtual hardware upgrade (1015572)
• IP address already in use error on a converted virtual machine (1012255)

Dlink DSL-G604T Bittorent problem

This is a very good article showing how to change the configuration for Dlink DSL-G604T so as to solve the bittorrent problem.

"D-LINK (& Several other major routers, netgear, linksys, etc.) has a maximum connection threshold. There are several firmware upgrades for improved p2p performance and also some 3rd party firmware. Please google for it. However, if you don't trust these 3rd party firmware, there is a workaround.

This problem is extremely easy to identify. You utorrent downloads continue running, all connections continues. For example, a Internet explorer downloads continues with no problem. But "non-continuous" connections stops. You can't ping your router. Your MSN Disconnects. You can't use internet explorer to surf the web. Then this is most probably your problem.

PLEASE NOTE THE FOLLOWING IS TO BE USED ON D-LINK DSL-G604T ADSL ROUTERS ONLY. ALTHOUGH OTHER ROUTERS MAY CONTAIN SIMILAR OS, DIRECTORY STRUCTURE & TELNET COMMANDS. USE IT AT YOUR OWN RISK.

This post documents how to automate this process, and how to simplify the re-issuing of commands should it be necessary to reboot or restart the router.

The process is called Telnet Scripting. To use it you need:
- a Telnet Scripting tool
- a file containing Telnet commands (that is, a script file)

Although you can use a normal telnet. You will have to type the commands all over again everytime the router restarts. This includes changing firewall settings, virtual server settings, etc. With a telnet scripting tool, you can do it with 2 clicks.

The Telnet Scripting tool that I use is TST10.EXE, written by Albert Yale. It can be downloaded from at http://users.telenet.be/tontonzen/gg/TST10.zip

Here's a trivial example of its use, a script to login to the DSL-G604T and display the help text:

192.168.1.1 23
WAIT "login:"
SEND "root\m"
WAIT "Password:"
SEND "admin\m"
WAIT "#"
SEND "help\m"
WAIT "#"

The script assumes the default IP address of the router (192.168.1.1) and the default login password (admin).

If the script were stored in the file help.txt then the command to issue it (assuming it is in the same directory as TST10.EXE) would be:

tst10 /r:help.txt

Info on the script syntax and the parameters of TST10.EXE can be found by running the program.

If you like, you can also write a .bat file on your own to run the script so all you have to do is double click to execute the commands. That is what I did.

A real life example of where this is useful is given below. This provides a script to set the NAT session parameters for success (?) with P2P applications, by increasing the number of concurrent NAT sessions and setting appropriate timeout values to ensure 'stale' session data is discarded. Acknowledgement and thanks to a post by samPT in this forum for the values.

192.168.1.1 23
WAIT "login:"
SEND "root\m"
WAIT "Password:"
REM This password is the administrator password you have set.
SEND "admin\m"
WAIT "#"
SEND "cd /proc/sys/net/ipv4/netfilter\m"
WAIT "#"
SEND "echo 4096 > ip_conntrack_max\m"
WAIT "#"
SEND "echo 50 > ip_conntrack_generic_timeout\m"
WAIT "#"
SEND "echo 5 > ip_conntrack_tcp_timeout_close\m"
WAIT "#"
SEND "echo 120 > ip_conntrack_tcp_timeout_close_wait\m"
WAIT "#"
SEND "echo 1200 > ip_conntrack_tcp_timeout_established\m"
WAIT "#"
SEND "echo 120 > ip_conntrack_tcp_timeout_fin_wait\m"
WAIT "#"
SEND "echo 60 > ip_conntrack_tcp_timeout_time_wait\m"
WAIT "#"
SEND "echo 10 > ip_conntrack_udp_timeout\m"
WAIT "#"
SEND "cd /\m"
WAIT "#"
SEND "exit\m"

Save this in a file (say) nat_sessions.txt, edit the default IP address and password to match your installation. Run a command prompt, change to the directory with the script + program, and execute it with:
tst10 /r:nat_sessions.txt /m

Just to confirm that these commands have taken effect and that the values have been written to the specific files, change directory and type them out. Here's an example:
cd /proc/sys/net/ipv4/netfilter/
cat ip_conntrack_max

You can extend this Telnet Scripting technique to do as many things as your Linux knowledge and the embedded toolset in the DSL-G604T allows. Which means that you perhaps won't need to wait for new firmware releases and fixes. Clearly this won't cover everything, but I'm sure you get the idea...

"