How to generate network impairments only on udp packets in linux - linux-kernel

I'm trying to generate impairments on my linux ubuntu 18.04 and use it as a hotspot to affect a mobile app with those impairments but I need it to affect only the UDP traffic.
I'm trying to test my app under bad network and when the test is done I want the app to upload the results, this flow should run in a loop so i can't switch networks between each iteration.
The problem is that linux tc using netem generates impairments both on TCP connections and UDP connections and I'm using the TCP connection for collecting the test results so the results are malformed or not coming at all.
I used it like this:
tc qdisc add dev <name> root netem delay XXms loss gemodel 20% 30% 1% 15%
do you know if there is a way to limit the tc using netem or any other way to affect only UDP packets?

I've found how to do it- so if it will help anyone I'm adding the answer:
the protocol 17 is for UDP but it can be replaced with other protocols and then only those protocols will be filtered
tc qdisc add dev <name> root handle 1: prio
tc filter add dev <name> protocol ip parent 1:prio 10 u32 match ip protocol 17 oxff flowid 1:1
tc filter add dev <name> protocol ip parent 1:prio 10 u32 match ip protocol 17 oxff flowid 1:2
tc filter add dev <name> protocol ip parent 1:prio 10 u32 match ip protocol 17 oxff flowid 1:3
after those lines you can add the network impairments:
tc qdisc add dev <name> parent 1:1 netem <impairments>
tc qdisc add dev <name> parent 1:2 netem <impairments>
tc qdisc add dev <name> parent 1:3 netem <impairments>
for fully understand what "prio" does I suggest to read here but basically it creates some kind of 3 routes for the packets to enter through, then we filter the traffic that come to take only the packets that are by the protocol of udp on every route and then I'm adding the network impairments on this route

Related

Can I send out a multicast packet through a dedicated NIC by Windows command?

There are 2 NICs in my Windows-based machine, the IP address of one of NICs is 192.168.1.x/24 and the other one is 192.168.2.x/24. The Windows-based machine run an application that need to send out the multicast packet 229.255.10.1 through two of the NIC. However, the multicast packet 229.255.10.1 can be sent out from the NIC 192.168.1.x/24 only. Can I use route add -p Windows Command to send out the multicast packet from the NIC 192.168.2.x/24?
I think you can use:
route -p add 229.255.10.1 mask 255.255.255.255 192.168.2.x metric 1
where 192.168.2.x is your IP on nic 2
It remains only a problem that I haven't found a solution yet: if your application send a packet before you add the root, you need to reboot PC. This is a problem if the second NIC is, for example, a VPN client and it starts after the application

Yosemite, double interface (eth/wifi) access a site through a specific interface

I have a macbook, connected with ethernet, and wifi.
A site (lets call it facebook) is blocked on one of the interface (ethernet)
but is open on the other (wifi), on the other hand eth is better (fastest and more reliable than the wifi) so I use eth as a priority interface (on top of network preferences), but in this way there is no access to the blocked site.
I would know if there is a way to say to the operating system or browser or other
software components that it must use the connection of wifi if and only if a connection on :80 over eth fail. this would be perfect...or any other means to solve the problem..
It's a matter of configuring a proper proxy?
Thanks in advance.
You could modify routing table to pass traffic to given host or network through chosen gateway.
List your routing table:
$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGSc 15 0 en0
default 192.168.0.1 UGScI 1 0 en1
[...]
In this case en1 is wifi. So to use wifi connection to a host x.x.x.x, route traffic to this host through 192.168.0.1 gateway:
sudo route add -host x.x.x.x 192.168.0.1
Or better add routing to entire network used by given service:
sudo route add -net x.x 192.168.0.1
The downside is that it may be difficult to determine an ultimate list of IPs, networks used by the service.
See man route.

Multicast Ping (Windows)

I am trying to implement server auto discovery so that clients will be able to see a list of servers available to connect to. I would like to auto discover servers even if they are in different subnets.
I have read that windows does not respond to broadcast ping, but is it possible to make all these servers to join a multicast group and use multicast ping on the group to see what servers are up?
Thanks
Try Zero configuration networking (Zeroconf).
Note multiple LAN segments requires routers to be configured to route multicast traffic, they do not by default. Similarly IGMP enabled switches are usually recommended for computer connectivity.

VMware and iptables

Is there a problem using VMware on Windows to host a virtual linux box running iptables? I have a configuration that seems to work on physical hardware but is flaky under VMware.
I'm using VMware to run a virtual linux 2.6.24 machine on a Windows 2003 Server host. The linux application is essentially a NATting router that runs iptables. The rules in the nat table include:
Chain foo_pre
target prot opt in out source destination
LOG all -- * * 0.0.0.0/0 0.0.0.0/0 [options here]
LOG all -- * * 0.0.0.0/0 10.10.1.33 [options here]
DNAT all -- * * 0.0.0.0/0 10.10.1.33 tcp dpt:80 to:192.168.0.33:8080
Chain PREROUTING
target prot opt in out source destination
foo_pre all -- * * 0.0.0.0/0 0.0.0.0/0
I'm seeing the incoming packets to 10.10.1.33:80 using tcpdump, and the first LOG generates messages, but neither the DNAT or the second LOG show the packets registering on their packet counters, the second LOG generates no messages, and tcpdump doesn't show the packets to 192.168.0.33.
The eth0 adapter is on the 10.10.0.0/16 network with a default gateway of 10.10.1.1; it has a secondary address of 10.10.1.33/32. /proc/sys/net/ipv4/config/eth0/forwarding is set to 1.
Is VMware the culprit, or am I missing something? Thanks!
Update: we've simplified the test environment. No NAT rules at all, just a linux VM running under a Win2k3 Server host. Test steps:
VM is bridged to host NIC. VM and host are on the same subnet, with the same default gateway as above.
VM communicates with devices both on and off its subnet: ICMP, TCP, UDP. Communication is bidirectional: it doesn't matter which equipment initiates it.
Engineer power-cycled the default gateway while poking at the system.
VM now communicates only with devices on its subnet. Any attempt to communicate through the gateway to the same equipment from Step 2 fails to put packets on the wire. tcpdump on eth0 on the VM shows outgoing packets with no response; WireShark on the host shows nothing on the physical NIC.
Stopping and restarting the VM does not change its behavior. Stopping the VM and replacing it with a different VM with appropriate IP address, etc. does not change the behavior.
The Win2k3 host continues to communicate normally, both on and off its subnet.
I can only conclude from this that "something happens" between the VM and the host: in the VMware drivers, or in the host's network stacks. I'm off to scour the web again.... it's hard to imagine we're the first to observe this.
Updates as they come. Thanks for your thoughts and discussion.
Your second log line is trying to match packets sent to 10.10.1.33, but you changed the destination address to 192.168.0.33 on the line above it.
I'm not sure why you don't see the outgoing packets in tcpdump yet. I assume you're running tcpdump on the linux VM itself. Is the VM sending packets on the same interface it's receiving, or is there a second virtual ethernet adapter? What machines are the various IP addresses assigned to (other than 10.10.1.33).
Regarding update:
I gather you're not using DHCP (people usually don't bother when using static IP addresses). Also, it sounds like the gateway sees one NIC using two IP addresses. Normally that should be ok, but it's always the details that get you.
Is it possible the gateway will only assign one IP address to the NIC and is ignoring traffic from the VM?
After your edit, I suggest an experiment: on your physical machine, configure your NIC to disable all hardware acceleration.

UDP and my computer?

I recently turned on Windows Firewall logging on my computer and started tracking incoming and outgoing connections. Something curious about the logfiles is that I have noticed numerous UDP packets (in fact, it constitutes basically all of my incoming traffic) that don't have my host as destination or source showing up in the logs.
I thought this might be a implementation detail for UDP (the packets are hopping over my computer in the subnet) but Wikipedia'ing UDP didn't enlighten me any more, and I don't see why my computer should be forwarding these packets in the first place.
Any ideas?
Edit 1: Here is what a log file line with the mysterious UDP packet looks like:
2008-10-11 16:04:31 ALLOW UDP 18.243.7.218 239.255.255.250 49152 3702 0 - - - - - - - RECEIVE
Is 239.255.255.250 a broadcast address? Now that you mention it, the UDP packets I'm seeing have very specific destinations, basically 224.0.0.252, 239.255.255.250, 18.243.255.255. I also get phantom ICMP pings addressed to 224.0.0.1.
The packets addressed to IPs starting with 239 and 224 are multicast packets. This is a way to address traffic to a group of computers without broadcasting it to an entire network. It is used by various legitimate protocols.
224.0.0.252 is the address used by the Link Local Name Resolution protocol.
239.255.255.250 is the address used by the Simple Service Discovery Protocol.
224.0.0.1 is the all hosts address, used by your router to see who on your network is willing to participate in multicast conversations.
The ones addressed to 18.243.255.255 look like broadcasts, again this is used by many legitimate protocols such as Bonjour.
As recommended by Luka, a good protocol analyzer like Wireshark will tell you precisely what each of these packets are and what they contain.
It depends on the type of connection you are on.
On most cable modem ISP's you are basicly on the same LAN as your neigburs, and can usualy see some of their traffic (like brodcast).
Id recomend you install packet sniffer and see what is realy going on.
Good multiplatform packet sniffer is Wireshark
Hard to say without analyzing the log data, but they could be broadcast packets on the segment, in which case you're system would listen to them. This is possible in IPv4 and IPv6.
Your system should not be forwarding them unless it's set up to route, but it can certainly be listening to packets all the time (various network protocols use UDP).

Resources