OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

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, 05:08)

nitroshift wrote:

@phantomsfbw

Follow openwrt timeline and look for the corresponding commit. The new driver will be included in the following day build.

nitroshift

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

Kaloz wrote:
nitroshift wrote:

@phantomsfbw

Follow openwrt timeline and look for the corresponding commit. The new driver will be included in the following day build.

nitroshift

Pushed it to both trunk and CC.

Kaloz wrote:
nitroshift wrote:

@phantomsfbw

Follow openwrt timeline and look for the corresponding commit. The new driver will be included in the following day build.

nitroshift

Pushed it to both trunk and CC.

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

Chadster766 wrote:
Kaloz wrote:
nitroshift wrote:

@phantomsfbw

Follow openwrt timeline and look for the corresponding commit. The new driver will be included in the following day build.

nitroshift

Pushed it to both trunk and CC.

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 wink It will be part of RC4/final.

Kaloz wrote:
Chadster766 wrote:
Kaloz wrote:

Pushed it to both trunk and CC.

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 wink It will be part of RC4/final.

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

Chadster766 wrote:
Kaloz wrote:
Chadster766 wrote:

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 wink 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 smile

Kaloz wrote:
Chadster766 wrote:
Kaloz wrote:

Although I've tried a few times, time travel is still beyond my skills wink 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 smile

Makes sense thanks.

Kaloz wrote:
Chadster766 wrote:
Kaloz wrote:

Pushed it to both trunk and CC.

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 wink It will be part of RC4/final.

Thanks a bunch smile

nitroshift wrote:

I believe esata led is tied to one of the OpenWRT initial mount points because it lights up right after the power LED.

did anyone found solution for this sata led always on?

Kaloz wrote:
nyt wrote:

Any news on that patch I submitted for the dts button states?  I see it was deferred.  Having the reset button immediately wipe the overlay when pressed is kind of a big bug lol.

Will check tomorrow. It's a trunk thingie, so not that harmful tongue What I'm wondering is, how it got reversed, I'm kinda sure I did it right back then smile

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.

Kaloz wrote:
Chadster766 wrote:
Kaloz wrote:

Pushed it to both trunk and CC.

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 wink It will be part of RC4/final.

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)

silvah wrote:
nitroshift wrote:

I believe esata led is tied to one of the OpenWRT initial mount points because it lights up right after the power LED.

did anyone found solution for this sata led always on?

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

nitroshift

nitroshift wrote:
silvah wrote:
nitroshift wrote:

I believe esata led is tied to one of the OpenWRT initial mount points because it lights up right after the power LED.

did anyone found solution for this sata led always on?

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

silvah wrote:

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, 12:14)

yeah but this is still a bug

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

Cheers,

silvah wrote:
nitroshift wrote:
silvah wrote:

did anyone found solution for this sata led always on?

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

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

gufus wrote:

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 tongue

Kaloz wrote:
gufus wrote:

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 tongue

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?

gufus wrote:

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, 03: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 ?

davidc502 wrote:

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.

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.