I don't want to update my firmware if I don't have to. The version I am on now is pretty stable. How do I find and load the `ROUTE` module?
It would only make sense to update the *dd-wrt* firmware if we knew a recent update contained the module. But I have no way of knowing that.
That's why I said, if it's NOT available, you're stuck, and may have to consider a capture file w/ tcpdump (who knows, maybe some dd-wrt firmware already has this installed). If NOT, then you need to install Entware and the tcpdump package. This does NOT change your firmware! It installs additional packages of apps and services on USB (or temporarily in memory, if you prefer, so it won't survive a reboot).
I have the hard requirement that I need to see live traffic.
I updated to the latest version(DD-WRT v3.0-r49392 std (06/29/22)) and here's the telnet from keeping the same rules:
Alternatively use Entware I think iptables-full will also have those
You're too nice... That is one of the many reasons why you been crowned DD-WRT's community M.C.H.O by me
Me on the other hand, would just point towards this thread
Teaching someone to fish rather than giving them a fish is my moto, maybe I'm just a grumpy and mean old fart
He is incredibly nice for giving support and I would like to buy him a couple of beers for the trouble. What's your paypal e-mail?
While I like doing things myself it takes alot of time and patience for someone with no experience building these firmwares or with dd-wrt than someone who is a professional in it. I don't plan to do anything more exotic than this so it makes sense to have a professional who works with everyday than someone like me who is only going to do this once or maybe even twice.
BTW, something I've noticed is that ROUTE/TEE will NOT work when the client doing the sniffing is behind a traditional client/repeater bridge.
In my case, it's an FT (FreshTomato) router and client bridge, but I suspect that would include other similar wireless bridges, since most use the same "hack". As soon as I substitute an end-to-end wired connection from the sniffing client to the router, it works perfectly.
This may be another case where a WDS bridge would probably work better.
Joined: 18 Mar 2014 Posts: 12885 Location: Netherlands
Posted: Fri Jul 01, 2022 6:16 Post subject:
Thanks @eibgrad for responding yes was past my bed time
I have to see again what is available on Entware was a long time ago I used it.
From what I know and from glancing through my notes it is like this (I think):
Older kernels (e.g. 2.6 like Fresh Tomato which is stuck on K2.6) use iptables 1.4 and those use the ROUTE target.
Entware might also still use iptables 1.4 for compatibility, not sure as it is a long time ago I used Entware
Newer kernels use iptables 1.8 which uses TEE
To use it on DDWRT you have to copy the three attached modules to your router (preferably to permanent storage but using /tmp should also work but then you have to redo after reboot)
I made a quick test with a router with standard DDWRT and copied the three modules to /tmp with WinSCP
Then do the following, open a CLI (telnet/Putty/SSH):
Code:
cd /tmp
modprobe ipv6
insmod nf_dup_ipv4.ko
insmod nf_dup_ipv6.ko
insmod xt_TEE.ko
Code:
root@MyR6400-v1:/tmp# iptables -t mangle -A PREROUTING ! -s 192.168.1.100 -j TEE --gateway 192.168.1.100
root@MyR6400-v1:/tmp# iptables -t mangle -A POSTROUTING ! -d 192.168.4.100 -j TEE --gateway 192.168.4.100
root@MyR6400-v1:/tmp# iptables -vnL -t mangle
Chain PREROUTING (policy ACCEPT 87 packets, 12597 bytes)
pkts bytes target prot opt in out source destination
222 25281 TEE all -- * * !192.168.1.100 0.0.0.0/0 TEE gw:192.168.1.100
Chain POSTROUTING (policy ACCEPT 367 packets, 69541 bytes)
pkts bytes target prot opt in out source destination
367 69541 TEE all -- * * 0.0.0.0/0 !192.168.4.100 TEE gw:192.168.4.100
I have not actually tested if it really works but at least the rules are there. But this is all I can do
When using insmod it usually checks if the kernel is the same, this will work on build 49392 and builds with the same kernel 4.4.302
When using an other kernel with different minor version, if necessary, you can force insmodding with:
dd-wrt x86 *does* have the xt_TEE module, so as you said, you can use the TEE target for dd-wrt.
However, I found that if you mirror the *whole* IP network (e.g., ! -s 192.168.1.100 and ! -d 192.168.1.100, where 192.168.1.100 is the sniffing client), it brings the router to its knees! I had to power-cycle to recover. But if I specify mirroring of just a single IP, it works fine. And remember, this is x86, not ARM or MIPS.
I don't know if the same can be said of something like the RT-AC68U until I have a chance to try it w/ your modules.
Anyway, just something to beware.
FWIW, I had no such problems w/ FT (FreshTomato) running on the RT-AC68U.
Thanks @eibgrad for responding yes was past my bed time
I have to see again what is available on Entware was a long time ago I used it.
From what I know and from glancing through my notes it is like this (I think):
Older kernels (e.g. 2.6 like Fresh Tomato which is stuck on K2.6) use iptables 1.4 and those use the ROUTE target.
Entware might also still use iptables 1.4 for compatibility, not sure as it is a long time ago I used Entware
Newer kernels use iptables 1.8 which uses TEE
To use it on DDWRT you have to copy the three attached modules to your router (preferably to permanent storage but using /tmp should also work but then you have to redo after reboot)
I made a quick test with a router with standard DDWRT and copied the three modules to /tmp with WinSCP
Then do the following, open a CLI (telnet/Putty/SSH):
Code:
cd /tmp
modprobe ipv6
insmod nf_dup_ipv4.ko
insmod nf_dup_ipv6.ko
insmod xt_TEE.ko
Code:
root@MyR6400-v1:/tmp# iptables -t mangle -A PREROUTING ! -s 192.168.1.100 -j TEE --gateway 192.168.1.100
root@MyR6400-v1:/tmp# iptables -t mangle -A POSTROUTING ! -d 192.168.4.100 -j TEE --gateway 192.168.4.100
root@MyR6400-v1:/tmp# iptables -vnL -t mangle
Chain PREROUTING (policy ACCEPT 87 packets, 12597 bytes)
pkts bytes target prot opt in out source destination
222 25281 TEE all -- * * !192.168.1.100 0.0.0.0/0 TEE gw:192.168.1.100
Chain POSTROUTING (policy ACCEPT 367 packets, 69541 bytes)
pkts bytes target prot opt in out source destination
367 69541 TEE all -- * * 0.0.0.0/0 !192.168.4.100 TEE gw:192.168.4.100
I have not actually tested if it really works but at least the rules are there. But this is all I can do
When using insmod it usually checks if the kernel is the same, this will work on build 49392 and builds with the same kernel 4.4.302
When using an other kernel with different minor version, if necessary, you can force insmodding with:
Code:
insmod -f
Sorry I don't see the attached packages in your post. Can I do this without installing entwire and just using the packages?
edit --
thanks for updating your post. Just to confirm the first IP is the address for the entire subnet and the second one should be the ip address of the monitor pc right?
