I have installed the multipath TCP connection and have 2 interfaces active in my pc. H want to see the mptcp connection working on my device. How do I check that subflows are actually created ?
I tried to connect with multipath-tcp.org and used iperf to check if infact subflows were created but I could see only a single entry in its result. I have seen the related questions, but they don't answer my question i.e. how exactly could i see the subflows in action.
You must connect to a mptcp enabled server to have subflows created otherwise mptcp just falls back to normal tcp. Also, you have to configure the kernel at runtime (you can select fullmesh option) as mentioned in the official website. And, obviolusly, you must have at least 2 interfaces active.
Then tools like iptraf, ifstat can be used to monitor bandwidth in/out.
I found this to be helpful.
1) Open two CLI at Linux environment;
2) Set Wireshark on for capture your packets:
Use option to filter TCP connections, that's make it easy to understand the TCP behavior.
3) Use first CLI to porform iperf as server (iperf -s) and the second to perform as client (iperf -c 127.0.0.1)
After all, you can check the subflows in the Wireshark. Further, you can explore it deeper :)
Related
I want to connect to a locked (cannot be modified and I do not have permissions to log into) windows vm which is hosted in a linux machine. Until now these two machines were communicating via port 2277. However for security reasons, the port 2277 is only accessible via localhost (127.0.0.1).
The original proposed solution was to use ssh-tunneling. However since the hosted windows vm will always stay with the linux machine, so I was thinking something simpler.
This Windows virtual machine has ip 192.168.0.1 and the default gateway is 192.168.0.2. The later is the ip address that my linux machine can see.
After searching the internet I tried
socat TCP4:192.168.0.1:2277,reuseaddr,fork TCP4:127.0.0.1:2277
as well as some other random combinations without success.
My understanding is that this failed because for socat to work both sockets must be open.
However the first one is not open by default (checked with ss -ltn) as I need to run the windows service first (which it cannot run as it cannot communicate with iphost:2277)
Any ideas on how to proceed?
Socat provides the retry=N and forever options to handle situations like this. Thus, try something like this:
socat -d -d TCP4:192.168.0.1:2277,reuseaddr,fork,forever TCP4:127.0.0.1:2277
With the interval=<seconds> option you can specify how long Socat waits after each failed attempt.
It turns out that the command that I wanted was the following
socat tcp-listen:2277,bind=192.168.0.1,fork,reuseaddr tcp:127.0.0.1:2277
The retry=N and forever options could be also useful.
I'm trying to make a portforwarding for different ports for communications, but it seems they are lost on reboot.
I'm using a script to make them, and it uses the following syntax:
upnpc -a 192.168.1.95 22 22 TCP
...
Since my system is made to actually stress the gateway to reboot, I need to have these ports open after a reboot. I could do it in the software (running the script if connection lost), but I don't want to do that unless it is absolutely necessary.
Do you have some idea of how to make a portforwarding with UPnP such that the forwarding is persisted after a reboot?
Port mappings are specifically not required to be persistent between gateway reboots, clients are supposed to keep an eye on the mappings and re-map when needed. WANIPConnection spec v2 also does not even allow indefinite mappings: another reason to keep the client running as long as you need the mapping to exist.
I have a sample Chrome packaged app which uses the Chrome sockets API to perform DNS service discovery. The heavy lifting is borrowed from the example here:
https://github.com/GoogleChrome/chrome-app-samples/tree/master/mdns-browser
I just use service names such as _pdl-datastream._tcp.local (instead of the default of _services._dns-sd._udp.local).
On both my Ubuntu and Windows setups (Chrome 25.0.1364.172), the app can successfully find my network printer; I can list its IP address and service instance name. However, it fails in Chrome OS on my Samsung Chromebook (Chrome 25.0.1364.173); nothing is found.
Any idea what the problem might be? Is this a known issue?
You should check if it's the default firewall. On a Chromebook by default I believe all incoming connections are blocked. If you're running in dev mode you can do the following to allow all incoming udp traffic to test whether this is the problem:
Press Ctrl+Alt+T to bring up a terminal window and type the following
shell
sudo iptables -I INPUT -p udp -j ACCEPT
Yes, Chromebooks default to a restrictive firewall. However, if the incoming packet matches an outgoing one, the incoming packet should be permitted. Here's the list of firewall rules.
According to the bug report created by Haw-Bin, this is verified as fixed since end of 2013.
Good day.
I need an application or script on Linux firewall which will monitor and close idle TCP connections to one site after some minutes. Till now I found cutter and Killcx, but this is command prompt tools and no idle detection.
Do you know any app or maybe firewall implementation for Linux with everything that I want in one package?
Thanks.
Perhaps you can hack something with "conntrack" iptables module. Especially the --ctexpire match. See man iptables.
After a small amount of research it seems that TCP MD5 Signatures are enabled on CentOS, but our PCI security software has indicated that our machines are not actually using it. How do I configure CentOS to use TCP MD5 Signatures?
Edit:
I was thinking that this was a global setting, but it is actually a per-socket setting. This means the application that is creating the socket (in this case Sun Application Server) has to be the one to specify this option.
TCP-MD5 is part of the Linux kernel; you will only have the capability if your kernel is compiled with the option enabled (you may be able to dump /proc/config.gz and if so, grep for CONFIG_TCP_MD5SIG) - the second part is an application that will actually perform the setsockopt() to enable TCP_MD5 for that connection.
If CentOS is anything like RHEL, the kernel config should be under /boot.
grep TCP_MD5 /boot/config-*
Otherwise, yes, it's a somewhat undocumented option to setsockopt().
Perhaps you are referring to TCP SYN cookies. To enable them:
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies