I try to issue this command on an ARM box with busybox installed:
ip link add link eth0 eth0.100 type vlan proto 802.1q id 100
I get an error:
argument of "protocol" must be "on" or "off"
What am I doing wrong?
I also got the same problem with busybox 1.23. I issued a bug on busybox bug tracking system. I also propose a solution that can help you.
The bug is at:
https://bugs.busybox.net/show_bug.cgi?id=8261
Regards.
I've tested IP commands in busybox-1.27.2 and it works fine in this version.
Former version in my router - busybox-1.26.2 has this error.
Related
I'm using WSL2 on Windows 10.
My dev stack is using a local webserver (localwp or wamp) on the host OS.
I use WSL2 as the main terminal (SSH, Git, SASS, automation tools, ...).
What I need is a way to connect to my host services (MySql) from the WSL2 system using a server name instead of a random IP address.
It is already possible for the Windows host to connect to WSL2 services with "localhost". Is there a solution to do it the other way?
You should use hostname.local to access Windows from WSL2 because that will use the correct IP. Note that hostname should be replaced with the result of the hostname command run in WSL2.
You can check the IP by running ping $(hostname).local from WSL2.
You also need to add a firewall rule to allow traffic from WSL2 to Windows. In an elevated PowerShell prompt run this:
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
The command above should allow you to access anything exposed by Windows from WSL, no matter what port, however bear in mind that any apps you've launched get an automated rule created for them when you first launch them, blocking access from public networks (this is when you get a prompt from Windows Firewall, asking whether the app should be allowed to accept connections from public networks).
If you don't explicitly allow, they will be blocked by default, which also blocks connections from WSL. So you might need to find that inbound rule, and change it from block to allow (or just delete it).
See info here:
https://github.com/microsoft/WSL/issues/4585#issuecomment-610061194
Well, your title and your question body don't seem quite aligned.
The question title says "use localhost", but then in the body you say "using a server name."
Accessing the Windows 10 service via the name "localhost" from WSL2? Let's just go with "no". I can think of a possibility of how to make it work, but it would be complicated.
But I think the second is really what you are looking for, so a couple of options that I can think of for accessing the Windows host services by hostname in WSL2:
First, and hopefully the easiest, WSL2 supports mDNS (WSL1 did not), so you should be able to access the Windows host as {hostname}.local (where {hostname} is the name of the Windows host (literally, in bash, ping $(hostname).local, since the assigned WSL2 hostname is that of the host Windows 10 computer). That works for me. While I don't recall having to do anything special to enable this, this Super User answer seems to indicate that you have to turn it on manually.
The second option would be to add your Windows host IP to /etc/hosts. If your Windows IP is static, then you could just add it manually to /etc/hosts and be done. If it's dynamic, then you might want to script it. You can retrieve it from inside WSL2 via:
powershell.exe "(Test-Connection -ComputerName (hostname) -Count 1).IPV4Address.IPAddressToString" (and other methods) and then use something like sed to change /etc/hosts.
Add the following code to ~/.bashrc or ~/.zshrc, and then use winhost to access the host ip。
sed -i -e '/winhost/d' /etc/hosts
win_ip=$(cat /etc/resolv.conf | grep nameserver | awk '{ print $2 }')
win_host="$win_ip winhost"
echo $win_host >> /etc/hosts
The last time I was facing this issue,
I downgraded to WSL1, and all the connections started working perfectly.
You can use:
wsl --set-version Ubuntu 1
This is the easiest approach to fix all connection related issues in WSL2.
I am trying to use MPLS on mininet I was able to install iproute2 and when I try something like this
ip route add 192.168.10.187/32 encap mpls 101 via 10.10.0.187
I get the error:
Error: either "to" is duplicate, or "encap" is a garbage.
Also when I try something like this
ip -f mpls route add 101 dev lo
I get the error:
RTNETLINK answers: Operation not supported
I checked my config file and set all of this, with no success:
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CT_NETLINK=y
CONFIG_SCSI_NETLINK=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_SCHED=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
I have the linux image 4.4.0-97-generic, any help will be greatly appreciated.
UPDATE
After doing some reading I found out that I am missing the directory /proc/sys/net/mpls
UPDATE 2
After doing more digging somehow, don't ask me how, I finally installed the missing module and now I have this error:
RTNETLINK answers: Invalid argument
UPDATE 3
I still have the previous problem stated in UPDATE 2, but I noticed when I try to add a new route, I get no complains and it actually shows on the routing table. However when I do:
ip -f mpls route show
I get no results
I think you have to load the kernel mpls modules first,
modprobe mpls_router
modprobe mpls_iptunnel
Then, allow the network interfaces to process mpls labeled packets (disabled by default)
echo 1 > /proc/sys/net/mpls/conf/IFNAME/input
(where IFNAME is the name of the network interface that will send/receive mpls packets)
And finally, specify number of entries that the kernel should allocate for labels (0 by default)
echo 2048 > /proc/sys/net/mpls/platform_labels
or else the iproute2 will gladly process your routes but the kernel won't know any of them (I've been bit by that, too).
References:
https://www.kernel.org/doc/Documentation/networking/mpls-sysctl.txt
http://www.samrussell.nz/2015/12/mpls-testbed-on-ubuntu-linux-with.html
My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.
I am debugging an SNMP trap problem using tshark (TShark 1.6.6) on a Linux platform. (The target platform does not support the wireshark GUI.) OIDs in PDUs are shown in numerical format even though I have MIBs installed in /usr/share/snmp/mibs with a link to that in /usr/local/share/mibs. I tried -V. There doesn't appear to be a tshark verbose or debugging option except for some memory debugging options. I have checked the man page and find nothing on SNMP or MIBs. I tried strace and I found a file /usr/share/wireshark/oid file but when I put the MIB directory there, I get a flex error, and a google search for what this mysterious file means turns up nothing. I can copy and paste the OIDs into an snmptranslate command and it correctly translates them. I tried creating a ~/.wireshark directory with smi_modules and smi_paths ("/usr/share/snmp/mibs"). I did a tshark -G currentprefs to see if there was a relevant preference but there isn't. I have googled this issue but I get way too much chaff to make any progress. I checked unix.stackexchange.com, superuser.com, and this site. I verified that people ask wireshark questions on this site (10,000 of them) to make sure it was on topic.
Example invocation:
tshark -R "snmp && ip.dst==<nms_ip>" -i eth0
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
4.675952 <agent_ip> -> <nms_ip> SNMP 115 sNMPv2-Trap 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0
Contents of ~/.wireshark/preferences:
name_resolve: mtC
name_resolve_load_smi_modules: TRUE
snmp.display_oid: TRUE
snmp.desegment: TRUE
snmp.var_in_tree: TRUE
How do I get the OIDs to be displayed in symbolic format, e.g. sysUpTimeInstance and snmpTrapOID.0?
I found the information Resolving SNMP OID in snmpbulkwalk and tshark useful.
Adding my MIBs to ~/.wireshark/smi_modules (via wireshark name resolution preferences), and ensuring the MIBs were located in the correct location
(on a mac I used dtrace to trace which files 'tshark' was accessing and located the path as /usr/share/snmp/mibs)
I'm using an Ubuntu 8.04 (x86_64) machine to connect to my employer's Cisco VPN. (The client didn't compile out of the box, but I found patches to update the client to compile on kernels released in the last two years.) This all works great, until my DHCP client decides to renew its lease and updates /etc/resolv.conf, replacing the VPN-specific name servers with my general network servers.
Is there a good way to prevent my DHCP client from updating /etc/resolv.conf while my VPN is active?
If you are running without NetworkManager handling the connections, use the resolvconf package to act as an intermediary to programs tweaking /etc/resolv.conf: sudo apt-get install resolvconf
If you are using NetworkManager it will handle this for you, so get rid of the resolvconf package: sudo apt-get remove resolvconf
I found out about this when setting up vpnc on Ubuntu last week. A search for vpn resolv.conf on ubuntuforums.org has 250 results, many of which are very related!
If you are using the Ubuntu default with NetworkManager, try removing the CiscoVPN client and use the NetworkManager vpnc plugin to connect to the Cisco VPN. This should avoid all problems, since NetworkManager then knows about your VPN connection.
I would advice following the advice from #Sean, but if that fails for whatever reason, it should be possible to configure dhclient to not request DNS servers in /etc/dhcp3/dhclient.conf
chattr +i /etc/resolv.conf should work. ( -i to undo )
But the better thing is to configure your dhclient.conf:
https://calomel.org/dhclient.html
Look at superceding domain-name-servers, and domain-name.
Also look at "send hostname;"
If it works at your work place, you will have a cool hostname for your PC and not some weird name that DHCP servers assign.
vpnc seems to be doing the right thing for my employer's cisco concentrator. I jump on and off the vpn, and it seems to update everything smoothly.
The DHCPclient daemon can be told not to update resolv.conf with a command line switch. (-r I think, depending on the client)
That's less dynamic, because you'd have to restart/reconfigure DHCP when you connect, but not too hard. Similarly, you could just stop the service, but you might lose your IP in the meantime, so I wouldn't really recommend that.
Alternatively, you could run the dhcpclient from within a cron job, adding the appropriate process checks.
This problem is much more noticeable on networks with low DHCP lease ages. There is a bug filed in Ubuntu's dhcp3 package launchpad:
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/90681
Which includes this patch in the description:
--- /sbin/dhclient-script.orig 2007-03-08 19:19:56.000000000 +0000
+++ /sbin/dhclient-script 2007-03-08 19:19:46.000000000 +0000
## -13,6 +13,10 ##
# The alias handling in here probably still sucks. -mdz
make_resolv_conf() {
+ # don't overwrite resolv.conf at RENEW time, since a VPN/PPTP tunnel may
+ # have updated it with remote DNS servers
+ [ "$reason" = "RENEW" ] && return
+
if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
# Find out whether we are going to mount / rw
exec 9>&0 </etc/fstab
This change to /sbin/dhcp-script stops DHCP client from overwriting /etc/resolv.conf when it renews its lease.