I enjoy playing around with OpenWrt. To most, the following, probably won't interest, but it was fun putting together.

At this point the router is logging IPTables-Dropped ONLY "outside interface" to a 15 GigaByte USB stick. From there, I have a log file monitoring program that catalogs the Source IP, Protocol, and Destination Port. It will also churn out how many drops happen in a day, hour, or month etc.

Where this also has some value is everything from logread AKA "System Log" is going to the USB stick as well. So, if in the future, there's some kind of issue, I won't have to worry about the log rolling.

Last items yet to be completed

1. Auto mount the USB after a reboot
2. Script the command that redirects the output of logread to the USB and place in rc.local.
3. Script the commands needed to always log the table drops into rc.local.

After that, it's off to the next thing.

(Last edited by davidc502 on 30 Jul 2015, 03:08)

Pushed it to both trunk and CC.

Kaloz,

  Thank you again for your tireless work on this router and contributions to the community at large.

Best

Phantomsfbw

Did you push to RC3 or will it be included in RC4?

Although I've tried a few times, time travel is still beyond my skills It will be part of RC4/final.

Funny, I wasn't sure if you could update a RC or not :-)

Technically I could, but a release (even if it's just an RC) should reflect the state it happened

Makes sense thanks.

Thanks a bunch

did anyone found solution for this sata led always on?

I think it's always been broken, but the new rc.button stuff makes it apparent since it's triggering the wipe on long press the first time you press, as opposed to just working and triggering a press before.  Anyway, easy to test/see what's going on.

Could be wrong about it always being broken, but I didn't see any changes when I checked to the dts patches.

I think I've got the time-travel subroutine nailed down now.  However I'm going to use it go forward to CES 2016 and purchase a couple of WRT1900AC Hardware Ver 3 units. (comes with Openwrt right out of the box)

This is an old issue that plagued McWRT. It doesn't exist in current OpenWRT.

nitroshift

For wrt1200ac it exist. Sata led is on - even that:

/sys/devices/gpio-leds/leds/caiman:white:sata/brightness = 0

You can turn the SATA light off and on for the WRT1200AC, but the brightness values are reversed from what you might expect:

To turn SATA LED off:

echo 1 > /sys/class/leds/caiman:white:sata/brightness

To turn SATA LED on:

echo 0 > /sys/class/leds/caiman:white:sata/brightness

I'm happily using mine as a VPN indicator with a hotplug script.  To set the default state to off, just go into LEDs in Luci and set the default state to checked and the trigger to none.

(Last edited by fecaleagle on 31 Jul 2015, 10:14)

yeah but this is still a bug

on a scale from 1-10 that has to be somewhere about 1 thousand

Cheers,

I read somewhere usb2 was a problem on Caiman also, but I don't own a Caiman.

silvah claims that, but I wasn't able to reproduce his issue.. not to mention his "fix" with a driver that doesn't even used could hardly work

Any timeline on RC4 release?

I use this for brute force attacks, works fine

iptables -N rate_limit
iptables -A rate_limit -p tcp --dport 22 -m limit --limit 3/min --limit-burst 3 -j DROP
iptables -A rate_limit -p tcp --dport 23 -m limit --limit 3/min --limit-burst 3 -j DROP
iptables -A rate_limit -p tcp -j REJECT --reject-with tcp-reset
iptables -A rate_limit -j DROP
#
iptables -I delegate_input -p tcp --dport 22 -m state --state NEW -j rate_limit
iptables -I delegate_input -p tcp --dport 23 -m state --state NEW -j rate_limit
iptables -I rate_limit -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

But when I restart my VPN tunnel it stops working and I have to restart the firewall.

Is this normal behaviour?

That's not normal.  Are you allowing the VPN to configure your routes automatically, or are you using an 'up' script?

I assume these rules are in your user firewall?  Is it possible they are failing only immediately after the vpn state changes?  The firewall does get restarted when the vpn does, so that seems entirely possible.

A dirty workaround until you can get everything straightened out would be to set a hotplug script on the VPN interface going down or coming up, where after a short delay, you could just restart the firewall.

(Last edited by fecaleagle on 1 Aug 2015, 01:39)

Logging is continuing to the USB stick, but noticed a particular drop that is confusing to me.

Fri Jul 31 22:21:28 2015 kern.warn kernel: [359194.902566] IPTables-Dropped: IN=br-wan OUT= MAC="MAC ADDRESSES" SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

Iptables is just supposed to be logging outside interface drops, but is the above drop from another zone? I'm thinking more is getting logged than just outside. Is this a correct assumption?

i am using stock firmware on my mamba. but i need multi wan activated on my router.
so i tried to flash chaos calmer rc1 to rc3 via web browser and then serial tftpd64 but in both ways i am getting stuck :

kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)

getting back to stock is working perfect either its 1.1.8 or 1.1.10
how can i be able to sort out the said issue ?

On the auto mount part.
Following http://wiki.openwrt.org/doc/howto/usb.storage should get you in the right direction (be aware, it is a little bit dated). Please note that the package block-mount is partly a stub if remember correctly and a big part is already available in OpenWRT.
If all goes well after a reboot you should see an (auto) mount point like /tmp/run/mountd/sda1.
If you want a more 'secure' mount point (for example you use several usb sticks in different ports you can edit /etc/config/fstab and add something like:

config 'mount'
        option  target  '/mnt/usb1'
        option  uuid    'f9123451-1234-1234-1234-12345678b05a'
        option  enabled '1'

Probably you need some additional packages to get the uuid of you partition.