I run an installation of Ubuntu as a server. I have noticed that it is constantly transmitting data over the Internet, which is a little unexpected.
Is there a tool I can use to determine the origin of the data (i.e. which program is sending the information)?
I have full root and physical access to the machine.
Thanks
You'll need a combination of tools. iptraf to see which port does the traffic (if it's local and not simply forwarded). "netstat -p" will show you which program is attached to a socket. iptraf is it's own package, netstat comes from net-tools which should be in default install.
I believe there is a netstat program available for linux too. You then can use tcpdump on the port in question.
Related
It's not enough for me to bind WSL ports to localhost because I need to run applications in WSL which must be run in and from my local network. Attempt to switch WSL virtual switch to external in Hyper-V manager leads to Access-denied error (when wsl instance is running) with following big problems with host's and/or WSL's network as a result until I reboot the host. When WSL distro is not running WSL virtual switch is invisible in Hyper-V manager (Virtual switch manager).
I have 2 question and will be very appreciated if someone could help me with that:
Is it a normal behavior - having got problem with network attempting to configure WSL virtual switch directly? As I recall there were no such problems with Hyper-V virtual machines - maybe just short losing of connectivity, not more.
Is there a way to configure WSL such way so it starts with WSL external switch any time I run it? Files .wslconfig and /etc/wsl.conf look to be useless for this - I haven't managed to find the solution in google.
Yes you can convert it to external from Hyper-v Manager. Just start the Hyper-v Manager as Administrator
It is indeed possible to get this configuration to work with IPV4. This is quite tricky, as you need to act on the Network configuration to set an IP address in the external network, and this requires systemd to be enabled.
Install WSL and Ubuntu distribution
First ensure that you have WSL2 installed, and install it if this is not the case
https://learn.microsoft.com/fr-fr/windows/wsl/install
WSL documentation:
https://learn.microsoft.com/en-us/windows/wsl/
It is key to have Ubuntu installed for WSL2, as the KDE installation is not compatible with WSL1.
wsl --install Ubuntu-20.04
It is important to have a recent version of WSL (1.0 as of this writing), as it allows you to use systemd.
Configure networking
By default, WSL installs with NAT and a dynamic IP which changes each time WSL is restarted.
There are also very limited options to access network services brought by WSL, as only TCP ports can be proxied with netsh, not UDP ports. This causes all sorts of issues with X, as it is using UDP ports, and I have been totally unable to make X windows desktops work, despite HOWTOs online claiming success.
If you need additional tools, now is the time to install them, as you are going to lose network connectivity for some time.
apt install net-tools
Change from internal to external network (Hyper-V manager)
You need to open Hyper-V manager and go to the virtual switch management. There is a WSL switch which by default is configured as “Internal network”. You need to change it to “External network”.
You also need to select which physical adapter you are going to connect to, Ethernet or Wifi.
At this point and until you finish network configuration, you no longer have any network connectivity.
Your virtual network card is now connected to the external network, but it is not configured, which we are going to do now by means of systemd.
Configure you virtual network card
From within WSL, edit file /etc/wsl.conf so that it contains:
[network]
generateResolvConf = false
[boot]
systemd=true
Create a file named /etc/systemd/network/26-fixed-ip.network containing (example):
[Match]
Name=eth0
[Network]
Address=192.168.1.60/24
Gateway=192.168.1.1
DNS=192.168.1.30
Select a fixed IP address in your external network range, and adapt the above parameters according to your case.
Configure DNS resolution
We have already instructed WSL not to generate resolv.conf each time it is started, as seen above.
It is now time to configure /etc/resolv.conf to contain:
nameserver 192.168.1.30
nameserver 192.168.1.5
domain xxxxxxxx.net
Check connectivity
Stop and start wsl (from a Windows cmd prompt):
wsl --shutdown
wsl
When wsl is restarted, it gets the fixed IP address, instead of a random one. You may ping any IP address and it works. You may also ping your ip address from another host on your LAN:
ping 192.168.1.60
Yes you can, but it seems to work only in IPv6 in my situation:
When I ran wsl --shutdown and opened Hyper-V Manager, the WSL switch appeared in Virtual Switch Manager, and can be successfully changed to external.
However, the IPv4 address could not be changed, and it's unable to access the Internet via IPv4 either. So I have to assign a NAT IPv6 network (fd68::/64 in my case) to make it work.
Maybe you should do some repair to your system if you can't reproduce this.
Note: if switch WSL is changed to external, your main adapter will become vEthernet (WSL) or something similar.
I am wondering how I can scan for open ports on all devices that are hooked up to the router. For example: I got 3 computer connected to router. Each computer has something going on on their localhost:3000. My aim is to find all of those opened hosts - to get the following results (ip address on local network):
10.0.0.5:3000
10.0.0.10:3000
10.0.0.19:3000
Any ideas?
If you're under linux you can use nmap command for this task, for Windows I thinks you can install it too but idk about Windows.
From the document, it seems the latest version of Open vSwitch supports multi-core.
In our OpenStack test environment which uses Open vSwitch on the host, it is observed that the sequence of the packets is changed when they are sent from the same VM to the physical network with the same IP destination. Is this something related to the multi-core processing on the host?
We also tried the similar test with kvm (as guest hypervisor) and use Linux bridge on the host, and the packet sequence was kept not changed.
Could anyone give me some hints on this?
This is one of OVS's normal forwarding behaviors.
http://openvswitch.org/pipermail/discuss/2012-April/007003.html
I am trying to share the internet with the Beaglebone Black from my laptop. Here is what I tried till now-
I connected Beaglebone Black to my laptop running Windows 8 via USB cable. Then, I went to network and sharing center. Then, the network which I want to share, I shared it with the Beaglebone(It says Local Area Connection). Now, I went to the Gate one SSH on Beaglebone and wrote - "ping www.google.com". But it said "Unknown Host".
Now, since the above didn't work, I connected the Beaglebone Black with the standard ethernet cable and again tried sharing my network, but it still didn't work.
Here is what I am trying to do-
If I am able to connect to internet, I want to set up VNC server and through that I want to load the GUI of linux on my laptop.
Any help will be greatly appreciated. If there is any other method to accomplish this, please tell me about it. I have tried most of the tutorials on the internet, but didn't succeed.
Here is the detailed answer, after long long waiting I finally figured out how to share internet on BBB. This question is being seen at least 10 times everyday so I though I should answer it by my own. (Also SO gave me Popular question badge for this!)
First thing I tried was:
I connected the BBB(running angstrom) to laptop (running windows 8). The laptop recognized the device and I was able to SSH it through putty.
Now, I tried to ping my computer back whose IP address is 192.168.7.1 .. This step never worked for me, my BBB was never able to ping my computer back but, I was able to ping the beaglebone itself through the provided IP that is 192.168.7.2 (which is obvious)
I searched everywhere on internet and did everything to overcome this glitch such as:
I made the default gateway in BBB to 192.168.7.1
/sbin/route add default gw 192.168.7.1
but that also didn't worked.
I previously thought that it is necessary for me to ping 192.168.7.1 in order to get the internet on BBB.
Since nothing was working I decided to skip this step.
I simply connected the BBB, and then went to network and sharing center in windows 8 and from there, I shared the internet connection from my wifi connection to the beaglebone.
As you will do this, you will see that BB will loose its connection from the putty (if you started putty before network sharing), This is because computer assigns an IP to the BB which you have to change to 'Obtain the IP automatially'
To do this right click and go to properties of the BB connection and then from the list select the IPV4 tcp/IP and go to its properties. In that, you will see the option 'Obtain IP automatically'
Now again start putty (as previous connection will get terminated) and you will see that BB is able to connect.
Now simply add the default gateway as I showed above and then you will be able to ping 8.8.8.8 or any other IP address. Now, simply add the nameserver like this:
cd /etc
more resolv.conf
nano resolv.conf
and add this line below nameserver 127.0.0.1
nameserver 8.8.8.8
and save it, you will be able to ping google.com.
Now comes the VNC server part. For that case also I was wrong. To connect to VNC server you do not need internet connection on the BBB. Yes, you will need that for installing the VNC server on it but not afterwards. Once it is installed, you have to simple do this in BB:
x11vnc -bg -o %HOME/.x11vnc.log.%VNCDISPLAY -auth /var/run/gdm/auth-for-gdm*/database -display :0 -forever
and press enter and BB will reply with VNC started at port 5900
Thats it, now comeback to windows and start VNC server, add the address 192.168.7.2 and you can see the GUI on the screen. I am also able surf internet on the beaglebone.
Thank you for the support and if I am wrong here in my question then please notify me.
Also if you have any doubt, refer to this awesome video my derek molloy: He has explained it very well and remember to skip the step of pinging back 192.168.7.1 if it is not working.
I have not yet figured it out. I will edit the answer once I get it.
1) On your Beaglebone:
sudo su
ifconfig usb0 192.168.7.2
route add default gw 192.168.7.1
2) Now share the network and make sure your pc's ip is 192.168.7.1 after you do
connect beaglebone black to router via ethernet
now use
adb tcpip 5555
adb connect bbb_ip:5555 then use adb shell
The problem you're facing is of resolving nameservers. If you're able to access the device through SSH (using PuTTy, for example), then you can provide it internet too- but the device needs to know where to look for.
The BeagleBone Black has a utility called Connman that manages its connections.
/usr/lib/connman/test has functions related to it.
Use ./set-ipv4-method in there to set different values. Be sure to set the nameservers right. If in doubt, use 8.8.8.8 as the only entry. Also note that the gateway for your BeagleBone must be your computer.
If you're not a newbie and need more detailed instructions, see this.
To continue from the answer provide by Vikas Arora, 3 things you have to do primarily to provide ethernet over usb connection to your Beaglebone. Firstly, share your PC internet connection with the local network made with Beaglebone, a process well explained above. And also setting up the IP address to be obtained automatically.
Secondly, setting up the nameserver to the public DNS server address 8.8.8.8 also explained above. But this setting is not persistent i.e. once you reboot, the settings will be lost. It is because the network manager on Angstrom 'connman' resets the etc/resolv.conf on startup. To correct that I disabled the connman service on my device by going to /lib/systemd/system and
firing commands
systemctl stop connman.service
systemctl disable connman.service
This will make your nameserver file persistent and you can always start connman service again if you need.
Thirdly you have to set your gateway to the address of your internet sharing machine also explained above. But this setting is also not persistent. To do that make a script like below in your home directory
echo "********Setting up the default gateway"
route add default gw 192.168.7.1
and make a service that will kick off on startup and trigger your script. A process well explained at
https://askubuntu.com/questions/506167/how-do-you-save-the-routing-table-on-the-beaglebone-blackangstrom
and
http://mattrichardson.com/BeagleBone-System-Services/
I have the Xming X Window Server installed on a laptop running Windows XP to connect to some UNIX development servers.
It works fine when I connect directly to the company network in the office. However, it does not work when I connect to the network remotely over a VPN.
When I start Xming when connected remotely none of my terminal Windows are displayed.
I think it may have something to do with the DISPLAY environment variable not being set correctly to the IP address of the laptop when it is connected.
I've noticed that when I do an ipconfig whilst connected remotely that my laptop has two IP addresses, the one assigned to it from the company network and the local IP address I've set up for it on my "local network" from my modem/router.
Are there some configuration changes I need to make in Xming to support its use through the VPN?
Chances are it's either X authentication, the X server binding to an interface, or your DISPLAY variable. I don't use Xming myself but there are some general phenomenon to check for. One test you can do to manually verify the DISPLAY variable is correct is:
Start your VPN. Run ipconfig to be sure you have the two IP addresses you mentioned (your local IP and your VPN IP).
Start Xming. Run 'netstat -n' to see how it's binding to the interface. You should see something that either says localIP:6000 or VPNIP:6000. It may not be 6000 but chances are it will be something like that. If there's no VPNIP:6000 it may be binding only to your localIP or even 127.0.0.1. That will probably not work over the VPN. Check if there are some Xming settings to make it bind to other or all interfaces.
If you see VPNIP:6000 or something similar, take note of what it says and remote shell into your UNIX host (hopefully something like ssh, if not whatever you have to get a text terminal).
On the UNIX terminal type 'echo $DISPLAY'. If there is nothing displayed try 'export DISPLAY=VPNIP:0.0' where VPNIP is your VPN IP address and 0.0 is the port you saw in step 3 minus 6000 with .0 at the end (i.e. 6000 = 0.0, 6010 = 10.0).
On the UNIX host run something like 'xclock' or 'xterm' to see if it runs. The error message should be informative. It will tell you that it either couldn't connect to the host (a connectivity problem) or authentication failed (you'll need to coordinate Xauth on your host and local machine or Xhosts on your local machine).
Opening Xhosts (with + for all hosts or something similar) isn't too bad if you have a locally protected network and you're going over a VPN. Hopefully this will get you started tracking down the problem. Another option that is often useful as it works over a VPN or simple ssh connectivity is ssh tunneling or X11 forwarding over ssh. This simulates connectivity to the X server on your local box by redirecting a port on your UNIX host to the local port on your X server box. Your display will typically be something like localhost:10.0 for the local 6010 port.
X can be ornery to set up but it usually works great once you get the hang of it.
Thanks for the help #Stephen and #Greg Castle, using it I've managed to resolve my problem.
To provide a basic guide for others (from scratch):
Using Xwindows on a Windows PC to connect to a UNIX server over a VPN
What you need to start with:
The Putty Telnet/SSH client, download putty.exe (for free) from:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
The Xming X server, download Xming (for free) from:
http://sourceforge.net/project/showfiles.php?group_id=156984
What to do:
Install both of the above on your Windows PC
From the Windows start menu select: Programs -> Xming -> Xming
Run the Putty.exe program in the location you downloaded it to
In the PuTTY configuration screen do the following:
Set the IP address to be the IP address of your UNIX server
Select the SSH Protocol radio-button
Click the SSH : Tunnels category in the left hand pane of the configuration screen
Click the Enable X11 forwarding check-box
Click the Open button
Logon as usual to your UNIX server
Check the directory containing the X windows utilities are in your path, e.g. /usr/X/bin on Solaris
Run your X Windows commands in your putty window and they will spawn new windows on your desktop
I got Xming and PuTTY working with Cisco VPN by replacing the PuTTY configuration in Connection > SSH > X11 > X display location, localhost:0.0, with VPNIP:0.0. VPNIP can be seen in the VPN statistics client address information by left-clicking on the VPN client lock icon and choose Statistics....
I didn't muck with the DISPLAY environment variable on the remote host. But, like others, I modified sshd_config on the remote host, adding these lines:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet
I have got same issue with Xming and Putty on a Windows 10 machine and found the solution here. I have overcome the problem just adding Tunnels to the session in PuTTY. But first you need to check;
sshd_config under /etc/ssh (in rhel7).
Enable X11 forwarding at left navigation pane Connections > SSH > X11
iptables under /etc/sysconfig/ (in rhel7). If ports are blocked and you have permission, open the ports for 6000. I have added below line before first reject line to open ports from 6000 to 6003. It may be more specific in your case.
-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 5901:5903,6000:6003 -j ACCEPT
Then;
Go to Connections > SSH > Tunnels in PuTTY and add a tunnel with Source Port=6000, Destination=127.0.0.1:6000 and check Remote radio button. Then click the Add button.
After your SSH connection established, set your DISPLAY variable manually with the command below:
export DISPLAY=127.0.0.1:0.0
More Information;
If you set DISPLAY variable as 127.0.0.1:1.0, it will communicate over 6001 port . In this case, you need to add another tunnel for port number 6001.
I had nothing but problems with Xming. When I could get it to work it was extremely slow (this is over a VPN). IMO X is not designed to run over slow connections its too chatty. And by slow connection I mean anything less then a LAN connection.
My solution was to use x11vnc. It lets you access your existing X11 session through VNC. I just ssh into my box through the VPN and launch:
$ x11vnc -display :0
That way I can access everything I had opened during the day. Then when I don't I just exit (Ctrl-C) in the terminal to close x11vnc.
Haven't have the exact problem, but I think you need to look at the xhost and make sure that the vpn remote is allowed to send data to the x server.
This link might help:
http://www.straightrunning.com/XmingNotes/trouble.php
You may have better luck doing X11 Forwarding through SSH rather than fiddling with your DISPLAY variable directly. X11 Forwarding with SSH is secure and uses the existing SSH connection to tunnel, so working through a VPN should be no problem.
Fortunately this is fairly straightforward with Xming. If you open your connection from within Xming (e.g. the plink option) I believe it sets up X11 forwarding by default. If you connect using another SSH client (e.g. PuTTY) then you simply need to enable X11 forwarding (e.g. 'ssh -X user#host'). In PuTTY the option is under Connection -> SSH -> X11 -> click on 'Enable X11 Forwarding'.
Make sure Xming is running in the background on your laptop and do the standard X test, 'xclock'. If you get a message like 'X connection to localhost:19.0 broken (explicit kill or server shutdown).' then Xming is most likely not running.
Also, make sure you're not explicitly setting your DISPLAY variable in any startup scripts; SSH will set up an alias (something like localhost:10 or in the example above localhost:19) for the X11 tunnel and automatically set DISPLAY to that value. Overwriting DISPLAY will obviously mean you will no longer be pointing to the correct X11 tunnel. The flip side of this is that other terminals that don't have SSH X11 Forwarding set can use the same DISPLAY value and take advantage of the tunnel.
I tend to prefer the PuTTY option but several of my coworkers use plink from within Xming.
putty + XMing - I had to set the DISPLAY environment variable manually to get things running (alongside with checking "Enable X11 forwarding" in putty - Connection/SSH/X11)
export DISPLAY=0:10.0
(it was set to "localhost:10.0", which did not work)
You have to add the Linux machine's DNS name(s) and IP address to the C:\Program Files\xming\X0.hosts file. File should contain:
LinuxBox.mydomain.com
LinuxBox
192.168.1.25
This is the right answer: https://www.slackwiki.com/X_Windows:_Remote_X_to_Windows_with_Xming