Run a script when a certain packet arrives at the ingress interface


I have a wired client to my router and all other clients are wireless.
I want to use a TBF to limit the rate of the wireless interface whenever the packet destined for
the wired client arrives at the router.

I was using Tcpdump to trigger the script but I am not sure it is real-time.

Is there a better way to do this?

not convinced of your need for such a "dynamic / userlevel" solution here... sounds like you think you want something kinda sticky/honeypit-like?

but...there is;

  • iptables (limit) match > tag > shape
  • cron > sh > read counters > adjust shape / reset counters
  • iptables LOG > logread / syslog+filters+files > shell > whatever
  • NFQUEUE for advanced userspace ( it's a bit heavy on openwrt in general tho' )

all depends on why you think you need it, your skill level... how much time you want to invest... and what you actually decide to implement.

I am actually using a Philips hue bridge on the ethernet. I was having a problem with Zigbee's performance like missed messages, so I thought of rate-limiting the router whenever it passes the packet to the bridge for a small-time around 500ms.

Can you provide the commands for the iptables and cron stuff you mentioned? I am an amateur at this.
I already have a script for the TFB. I just need to match the MAC address of the bridge in the destination of the packet and run the script

so you want to introduce 500ms delay to a single wired host, per source wireless ip/mac;

  • indefinately?
  • only for the first few packets / seconds when seen?
  • varies... you only doing it to debug and issue with some other hosts not on wired?

i'm still not really clear on the goal here...

why even bother with the detection side of things? what's wrong with a static cap on the hue bridge?

why do you think a cron based solution will be good? what did you expect it to do?

( fwiw: your issue sounds like layer 1/2 zigbee connectivity or higher up the zigbee stack = nothing to do with hue bridge wired at all )

No I want to introduce the delay on the wireless interface for all wireless hosts.

  1. I want to detect a packet sent from my PC to the Philips Hue bridge(which is on ethernet).
  2. After detecting the packet, I want to run a tbf(very small rate around 1Mbps) for 500ms on the wireless interface to make sure the router does not interfere with the future Zigbee transmission of the bridge(which will happen sometime in the next 500ms). After 500ms I remove the TBF or increase it's rate to a large value.

My hypothesis is that under low interference from the router, the Zigbee packet will suffer less latency.

I can rate limit the router permanently but that would defeat the purpose.

1 Like

thankyou for describing exactly better the goal...

fyi.... "interferance" != "contention/packet load"... simply limiting the wireless interface rate (l3) doesn't really fall into cutting down on "interference" (radio)... ( is it a weak router? what hardware is it? )

also... 500ms... low rate... for that client only? for all clients but that client, for all clients?

i think you should do a search here/online for "iptables --limit" or setup some classes to classify the right traffic higher... if your intent on approaching this at the ip level...

but if it were me... i'd be isolating / tweaking / testing at the radio/zigbee level before messing with complex layer 3 rates... ( tho' in the future adequate classes will really help )

slowing something down to improve an "interference" issue, while kindof cool, doesn't really seem like the right approach to me... ( but don't let me stop you from trying if you really want to! :face_with_monocle: )

I am using the LINKSYS EA6350 router. I mean I want to limit for all wireless clients. I believe when I send the packet towards the Hue bridge that would go to the ethernet interface. Then the Hue bridge will convert it to a Zigbee packet and send it. I want to make sure the router does not transmit too many packets(I assume with 1 Mbps and 1400 bytes packet, it will send around 45 packets in 500ms which is much lower than a 10Mbps rate). I assume this will give Zigbee a better chance to get access to the medium and transmit its packet. I can also completely stop the wireless interface but don't want to.

well here is a "template" you can use to connect iptables LOG with a script... it's enough to get you started but you'll probably need to use tcpdump/raw/netdev/ebtables due to it being "non-routed + non-input" transmission over the router.... ( search the forum for "iptables interface" / "iptables wireless" / "iptables lan traffic" or create a new post about matching "wireless LAN<>LAN wired traffic if you want to still use iptables and your having issues matching )

yeah... it might... at least enough to test with... just remember "medium" is a whole lot more than just load.

#you will probably need ipt netdev to make a rule to match an interface or maybe brtables or whatever
#or use tcpdump... to trigger a logger message or just "read" here instead of logread

#INPUT wont be correct for you it is connections to the router the point is the LOG TEXT
iptables -D INPUT -s zigbee.ip/32 -j LOG --log-prefix "LOGWATCHERZIGBEE" 2>/dev/null
iptables -I INPUT -s zigbee.ip/32 -j LOG --log-prefix "LOGWATCHERZIGBEE"

logread -f | while read THIS; do
	THISclean=$(echo $THIS | sed 's/LOGWATCHER//g')
	case "$THIS" in
		#if ! islimited then...
		echo "run command zigbee i.e: / limit 500ms $THIS"

exit 0

Thank you very much I will try that.
One question- is tcpdump real-time? I mean the results which I will get using iptables matching will that be quicker than the one from tcpdump (tcpdump match src a.b.c.d and dst b.c.d.e )

I already have a script that runs my tc tfb script after getting results from tcpdump. I am not sure whether this is real-time.

depends on the filters and 'ms' tolerances... technically... tcpdump can introduce some delays... use it with a very specific filter... on that router you should be ok ( on the closer side of the tolerances )

okay. I am indeed running the tcpdump on the router

I fail to understand why you are choosing this rate limiting approach to mitigate what sounds like a radio interference issue. Rate limiting won't guarantee you are avoiding collisions.

Why not simply pick non-overlapping channels and be done with it?

You make a very valid point. However, I don't have any free channels. Every free channel is occupied by my neighbors with everyone having a high RSSI. I do this just to make sure I don't suffer interference from them and control the only Wi-Fi I can control(mine).

I only do the rate-limiting part as the last solution. Any other better method would be appreciated :smiley:

Surely your own wifi rssi is higher than the neighbours.

Select a channel for ZigBee that corresponds with lowest wifi rssi.

In that case I'm afraid temporarily halting your own router won't have much effect.
If the spectrum is indeed so saturated your best bet is to select Zigbee channel 26 (or 25).

(just to check, you didn't put your hue bridge right next to your router by any chance? The band-pass filters on these things aren't that great)

Good luck.

1 Like

I don't understand the theory. Why temporary halting the router won't help me? I mean if the router is not sending any packets that means there is no radio interference right?

everyone is almost equal and high.

Well, it;s not only your router, is it?
If your spectrum really is as congested as you say it is, all those other routers and devices will keep transmitting and gobble up the space your router has cleared. (wifi has no neat TDM mechanism, it's CSMA/CA - shout and hope you get through, if not, shout again). Throttling your router won't even stop it from transmitting beacons and the like.

So, the router won't entirely stop transmitting (although it will indeed be a lot less traffic) and all the other devices in your vicinity definitely won't stop transmitting either. So no, if your spectrum truly is congested, there will be plenty of radio interference.

1 Like

yeah but you can argue that the other routers and their devices are on a different frequency. Yes, it won't affect the beacons but since I want to do this for a small time ~500ms , I don't believe that would be an issue