I installed the mptcp kernel on my machine. I tried to test MPTCP by running iperf -c multipath-tcp.org (both end-ponts are MPTCP CAPABLE).
I tried to test if iperf lists the subflows created. I have an active wifi interface + active wired interface. But still iperf showed only the one with the wired interface:
Client connecting to multipath-tcp.org, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.42.123 port 52983 connected with 130.104.230.45 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-22.7 sec 384 KBytes 139 Kbits/sec
THis shouldn't be the case. My wired link was too slow so, even if the flow would have started here, surely subflow would be there in the wifi interface as well.
How could I actually see that MPTCP is in fact creating subflows ?
I saw the question here but my cat proc... file is showing
sl loc_tok rem_tok v6 local_address remote_address st ns tx_queue rx_queue inode
0: B491F32C CDF952DC 0 0B2BA8C0:8E9C 2DE66882:1389 01 02 00000000:00000000 203077
which doesn't relate to any subflows I guess.
Maybe you can check the mptcp setting with sysctl net.mptcp,the path manager should be setted to fullmesh rather than default to establish multiple flows.
sysctl -w net.mptcp.mptcp_path_manager=fullmesh
sysctl -w net.mptcp.mptcp_enabled=1
Further explanation of mptcp setting can be viewed at http://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP
Related
I'm trying to launch a SNMP query from a pod uploaded in an Azure cloud to an internal host on my company's network. The snmpget queries work well from the pod to, say, a public SNMP server, but the query to my target host results in:
root#status-tanner-api-86557c6786-wpvdx:/home/status-tanner-api/poller# snmpget -c public -v 2c 192.168.118.23 1.3.6.1.2.1.1.1.0
Timeout: No Response from 192.168.118.23.
an NMAP shows that the SNMP port is open|filtered:
Nmap scan report for 192.168.118.23
Host is up (0.16s latency).
PORT STATE SERVICE
161/udp open|filtered snmp
I requested a new rule to allow 161UDP from my pod, but I'm suspecting that I requested the rule to be made for the wrong IP address.
My theory is that I should be able to determine the IP address my pod uses to access this target host if I could get inside the target host, open a connection from the pod and see using netstat which is the IP address my pod is using. The problem is that I currently have no access to this host.
So, my question is How can I see from which address my pod is reaching the target host? Some sort of public address is obviously being used, but I can't tell which one is it without entering the target host.
I'm pretty sure I'm missing an important network tool that should help me in this situation. Any suggestion would be profoundly appreciated.
By default Kubernetes will use you node ip to reach the others servers, so you need to make a firewall rule using your node IP.
I've tested using a busybox pod to reach other server in my network
Here is my lab-1 node IP with ip 10.128.0.62:
$rabello#lab-1:~ ip ad | grep ens4 | grep inet
inet 10.128.0.62/32 scope global dynamic ens4
In this node I have a busybox pod with the ip 192.168.251.219:
$ kubectl exec -it busybox sh
/ # ip ad | grep eth0 | grep inet
inet 192.168.251.219/32 scope global eth0
When perform a ping test to another server in the network (server-1) we have:
/ # ping 10.128.0.61
PING 10.128.0.61 (10.128.0.61): 56 data bytes
64 bytes from 10.128.0.61: seq=0 ttl=63 time=1.478 ms
64 bytes from 10.128.0.61: seq=1 ttl=63 time=0.337 ms
^C
--- 10.128.0.61 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.337/0.907/1.478 ms
Using tcpdump on server-1, we can see the ping requests from my pod using the node ip from lab-1:
rabello#server-1:~$ sudo tcpdump -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:16:09.291714 IP 10.128.0.62 > 10.128.0.61: ICMP echo request, id 6230, seq 0, length 64
10:16:09.291775 IP 10.128.0.61 > 10.128.0.62: ICMP echo reply, id 6230, seq 0, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
Make sure you have an appropriate firewall rule to allow your node (or your vpc range) reach your destination and check if you VPN is up (if you have one).
I hope it helps! =)
Hello guys i need to resolve this problem (all server have installed centos 7): i'm trying to create a gre tunnel through vps (in Italy - OpenVZ) and a dedicated server (in Germany), but they do not communicate internally (ping and ssh command tests). Next i create a gre tunnel trought vps (in Italy - OpenVZ) and vps (in France - KVM OpenStack) and their communicate, i next i had create a tunnel trought vps (in France - KVM OpenStack) and a dedicated server (in Germany) their communicate. I can not understand why the vps (in Italy - OpenVZ) and the dedicated server (in Germany) do not communicate, ideas on how I can fix (
I also tried with iptables disabled, firewalld is not enable)? Thanks
In other words:
In other attempts (by this i mean that i managed to successfully create the GRE Tunnel between these machines):
The VPS (in France) and VPS (in Italy) communicate internally (ping and ssh command tests)
The VPS (in France) and Dedicated Server (in Germany) communicate internally (ping and ssh command tests)
Problem (by this i mean that i could not successfully create the GRE Tunnel between these machines):
The VPS (in Italy) and Dedicated Server (in Germany) do not communicate internally (ping and ssh command tests). I also asked hosting services if they had any restrinzione but nothing.
My configuration:
VPS command for tunnel:
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
iptunnel add gre1 mode gre local VPS_IP remote DEDICATED_SERVER_IP ttl 255
ip addr add 192.168.168.1/30 dev gre1 ip link set gre1 up
Dedicated server command for tunnel:
iptunnel add gre1 mode gre local DEDICATED_SERVER_IP remote VPS_IP ttl 255
ip addr add 192.168.168.2/30 dev gre1
ip link set gre1 up
[root#VPS ~]# ping 192.168.168.2
PING 192.168.168.2 (192.168.168.2) 56(84) bytes of data.
^C
--- 192.168.168.2 ping statistics ---
89 packets transmitted, 0 received, 100% packet loss, time 87999ms
[root#DE ~]# ping 192.168.168.1
PING 192.168.168.1 (192.168.168.1) 56(84) bytes of data.
^C
--- 192.168.168.1 ping statistics ---
92 packets transmitted, 0 received, 100% packet loss, time 91001ms
[root#VPS ~]# tcpdump -i venet0 "proto gre" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes ^C 0 packets captured 1 packet received by filter 0 packets dropped by kernel
[root#DE ~]# tcpdump -i enp2s0 "proto gre" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel
[root#VPS ~]# lsmod | grep gre
ip_gre 4242 -2
ip_tunnel 4242 -2 sit,ip_gre
gre 4242 -2 ip_gre
[root#DE ~]# lsmod | grep gre
ip_gre 22707 0
ip_tunnel 25163 1 ip_gre
gre 13144 1 ip_gre
Console image with full command output
If ip_forwarding is required for the tunnel to work, you need to do /sbin/sysctl -p
And what does the output of ip tunnel show and ip route show on both the ends
I have a Linux (3.14.36) embedded board acting as a WiFi AP.
The WiFi chipset doesn't support monitoring mode.
My laptop(the client) is connected to this board by WiFi
The WiFi AP is acting as a network bridge to another computer, and doesn't provide an IP adress to the client (the WiFi AP only has the MAC address of the client)
I want to monitor the signal strengh of the connection WiFi AP <-> Client and be able to trigger a "refresh" of the signal strengh value.
Doing : iw dev wlan0 station dump gives me :
Station xx:xx:xx:xx:xx:xx (on wlan0)
inactive time: 123820 ms // <-- The problem
rx bytes: 10291
rx packets: 60
...
signal: -65 dBm // What I want to refresh
...
I understood that the signal strengh is updated every time there is a network activity. (So, in the example above, it has been refreshed 123s ago).
How can I force a refresh of this value ? (By forcing the AP to send "something" to the client for example) Knowing that the board/WiFi driver/WiFi device doesn't support tools such as iwconfig
For anyone finding this thread now:
I had this issue and my solution was to ping the device before doing the iw dump, e.g.
Get the list of of connected MAC addresses:
iw dev wlan0 station dump | grep 'signal' | awk '{print $2}'
Then get the IP address from these MAC addresses (alternatively you could use arp):
ip neigh | grep 'ma:ca:dd:re:ss:ss' | awk '{print $1}'
Then ping each of those:
ping -c 1 'IP.address'
Then get the refreshed signal for that MAC address
iw dev wlan0 station get 'ma:ca:dd:re:ss:ss' | grep 'signal' | awk '{print $2}'
I wrapped all this up in a Python script and it seemed to give reliable data.
I'll give it a try:
You're embedded so I guess you have busybox. You have no IP but you may then use arping (if this applet is not configured in your busybox build, change the config) to send something small and useless that may wake up the thing. What IP to use for your ARP requests? Well it seems you can use a "dummy" IP.
I'm running this on a PC but I do have busybox with its arping, and I use a wired interface, but here is the concept:
jbm#sumo:~/sandbox/iw$ sudo busybox arping -w 1 -U -I eth0 0.0.0.0
ARPING to 0.0.0.0 from 192.168.1.66 via eth0
Sent 2 probe(s) (2 broadcast(s))
Received 0 reply (0 request(s), 0 broadcast(s))
The useful thing is that though the "dummy" IP, I can check with tcpdump that the arp requests do actually go on the wire (or in the air in your case):
jbm#sumo:~$ sudo tcpdump -i eth0 -v arp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:42:20.111100 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 0.0.0.0 (Broadcast) tell sumo, length 28
10:42:21.111206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 0.0.0.0 (Broadcast) tell sumo, length 28
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
So sending ARP request on your wireless interface may be enough to "wake up" your connection and refresh your RSSI.
EDIT:
See the interesting uses and properties of IP 0.0.0.0 here:
https://en.wikipedia.org/wiki/0.0.0.0
EDIT 2:
Re-thinking about it, I realized there will be a problem if your wireless interface does not have an IP itself. Which, if I'm not mistaking, may not necessarily be case in your bridging configuration. In such case, arping will not have a source address to build its request packets (nor will know how to listen for responses), and will fail.
But you can create your own "mini-unidirectional arping", using an AF_PACKET socket and build your own ARP request packet with a dummy/random source IP address. It will be unidirectional because the response to your forged ARP request, if any, would go to to the random source IP which may and preferably should not exist. But it the principle of just awaking your wireless connection by sending "something", that may do the trick.
For inspiration on how to code this "mini-unidirectional arping", have a look at busybox implementation from its udhcpc/udhcpd (it's simpler than the full-blown arping busybox applet):
https://git.busybox.net/busybox/tree/networking/udhcp/arpping.c#n38
The from_ip parameter is what you want to forge. You can use your actual MAC as from_mac, just for the sake of dignity :-) You don't even have to wait for a response (starting line 89), so that would be something like 50 lines of C code + a little main if you want to add a few options to it.
I'd like to configure GPSD to take as input an UDP multicast stream.
I have a background service which sends NMEA frames on UDP multicast, port 5098 (254.0.0.50:5098)
I've tried :
gpsd udp://254.0.0.50:5098 -n -N -D 5
but it's not working.
Here is the result :
gpsd:INFO: launching (Version 3.9)
gpsd:IO: opening IPv4
gpsd:IO: opening IPv6 socket
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: PPS thread launched
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device udp://254.0.0.50:5098 at slot 0
gpsd:PROG: no /etc/gpsd/device-hook present, skipped running ACTIVATE hook
gpsd:INFO: opening UDP feed at 254.0.0.50, port 5098.
gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
gpsd:PROG: PPS thread awaiting device activation
gpsd:ERROR: UDP device open error can't connect to host/port pair.
gpsd:ERROR: initial GPS device udp://254.0.0.50:5098 open failed
gpsd:PROG: PPS thread awaiting device activation
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 65534
gpsd:INFO: startup at 2015-05-05T13:38:33.000Z (1430833113)
gpsd:PROG: PPS thread awaiting device activation
Do you have an idea where I'm wrong ?
Thanks by advance.
Sincerely.
Thom
I had exactly the same problem. I was trying to use an UDP multicast coming from 192.168.1.100 port 10110, but using gpsd udp://192.168.1.100:10110 -n -N -D 5 didn't work, neither did listening on localhost.
After much research I found that it works by using
gpsd udp://192.168.1.255 -n -N -D 5
Note that 192.168.1.255 is a non-existent ip on my network. It seems that gpsd is only able to fetch UDP multicast messages from the non-existent .255 node.
254.0.0.50 is not a valid multicast address.
Valid IPv4 multicast addresses are in the range 224.0.0.1 - 239.255.255.255. Addresses in the range 240.0.0.0 - 255.255.255.255 are reserved.
I have been using wire-shark to analyse the packets of socket programs, Now i want to see the traffic of other hosts traffic, as i found that i need to use monitor mode that is only supported in Linux platform, so i tried but i couldn't capture any packets that is transferred in my network, listing as 0 packets captured.
Scenario:
I'm having a network consisting of 50+ hosts (all are powered by windows Except mine), my IP address is 192.168.1.10, when i initiate a communication between any 192.168.1.xx it showing the captured traffic.
But my requirement is to monitor the traffic of 192.168.1.21 b/w 192.168.1.22 from my host i,e. from 192.168.1.10.
1: is it possible to capture the traffic as i mentioned?
2: If it is possible then is wire-shark is right tool for it (or should i have to use differnt one)?
3: if it is not possible, then why?
Just adapt this a bit with your own filters and ips : (on local host)
ssh -l root <REMOTE HOST> tshark -w - not tcp port 22 | wireshark -k -i -
or using bash :
wireshark -k -i <(ssh -l root <REMOTE HOST> tshark -w - not tcp port 22)
You can use tcpdump instead of tshark if needed :
ssh -l root <REMOTE HOST> tcpdump -U -s0 -w - -i eth0 'port 22' |
wireshark -k -i -
You are connected to a switch which is "switching" traffic. It bases the traffic you see on your mac address. It will NOT send you traffic that is not destined to your mac address. If you want to monitor all the traffic you need to configure your switch to use a "port mirror" and plug your sniffer into that port. There is no software that you can install on your machine that will circumvent the way network switching works.
http://en.wikipedia.org/wiki/Port_mirroring