8

I'm doing some testing of an application I am working on, and I need to be able to silently drop outgoing UDP packets for a short period of time to replicate a possible failure mode.

Is there any way to do this?

Note: iptables DROP is not silent for outgoing messages! When a send() or similar call is dropped by iptables, it returns EPERM for some bizarre reason (see here. Unfortunately, I can't use that answer as my destination is a single hop away).

xtables-addons used to have a STEAL verb, but it got removed a few years ago for no reason I can find.


I've now tried using bogus routes in the routing table, and unfortunately, that appears to break both directions of comm traffic.
For the test I need to do, I have to allow inbound UDP traffic, and as soon as I install the bogus route, the streaming incoming packets immediately halt, though the source is still sending them.

  • 1
    Far from a complete/tidy solution but I've needed similar test condition in the past. In my case adding a bogus static route to the server I'm connecting worked well. – steve Sep 9 '15 at 21:51
  • @steve - A bogus route appears to break things in both directions, and I need to maintain the RX direction's functionality. – Fake Name Sep 10 '15 at 19:31
2

How about adding dummy interface and setting the route to that interface?

# ip link add dummy0 type dummy
# ip link set dev dummy0 up
# ip route add 8.8.8.8/32 dev dummy0
# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

It always sends packets for any (neighbor or remote) addresses on dummy0.

# tshark -i dummy0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'dummy0'
  1   0.000000   10.10.0.59 -> 8.8.8.8      ICMP 98 Echo (ping) request  id=0x1ce0, seq=1/256, ttl=64
  2   1.007348   10.10.0.59 -> 8.8.8.8      ICMP 98 Echo (ping) request  id=0x1ce0, seq=2/512, ttl=64
  3   2.015394   10.10.0.59 -> 8.8.8.8      ICMP 98 Echo (ping) request  id=0x1ce0, seq=3/768, ttl=64
  • Unfortunately, this appears to disallow incoming packets that match the route from other interfaces. As such, it doesn't really work (it breaks the open UDP rx stream I need to allow to continue). – Fake Name Sep 10 '15 at 19:29
2

Adding a route is breaking incoming traffic due to reverse path filtering. Simple solution: disable reverse path filtering on the interface:

echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

(use your incoming interface in place of eth0 above).

You could also use the REDIRECT target (send the packet to, e.g., a netcat listening for it—nc -l -u -p 1234 > /dev/null). A more complicated version would be NFQUEUE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.