The information here is so far out of date that this post is meaningless.

This post is about 3.18.10 and 10.2.8.5.

The current released versions are 3.18.18 RC3 (or 3.18.20 ?) and Driver 10.3.0.8 (recalled and rolled back to 10.3.0.3 on August 19 by David Lin - Belkin) here:

https://forum.openwrt.org/viewtopic.php … 39#p288439

Posts on yesterday's firmware (3.18.10 and 10.2.8.5) that far back don't help.

Off topic but would really appreciate some help.

I have ssh access over WAN to my router. Im trying to limit external IPs that can ssh to the router.I've tried adding several IPtables rules but i cant seem to block ssh access.

Currently the /etc/config/firewall has the following rule that enables ssh over WAN in the first place
---------------------------------------------------
config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'tcp udp'
        option dest_port '22'
        option name 'ssh'
---------------------------------------------------

Now i've added the following rulers in the custom filewall rules, where x.x.x.0 is the external i want to allow for ssh access over WAN. eth1 is my WAN port on the router:

-------------------------------------------------------------------------------------------------------------------------------------------
iptables -A INPUT -p tcp -i eth1 --dport 22 -s  x.x.x.0/24 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -i eth1 --dport 22 --state NEW,ESTABLISHED,RELATED -j DROP
-------------------------------------------------------------------------------------------------------------------------------------------

however even with that rule i can ssh from WAN IP to the router. Its worth mentioning that i do have a port forwaring rule on the router that routes port 22 from WAN to the router itself. I see that, that rule itself allows access from external IP. Could that rule be over writing my iptables rule?

Any help please?

EDIT: ok so i can confirm that the first set of firewall config in /etc/config/firewall seems to be the "global" rule. Any further iptables rules that i add in the firewall dont seem to be taking affect.

(Last edited by alirz on 27 Aug 2015, 23:38)

How's this?

Interface wlan1
    ifindex 8
    wdev 0x100000002
    addr 00:25:9c:xx:xx:xx
    ssid RickStepIsAPrick
    type AP
    wiphy 1
    channel 161 (5805 MHz), width: 80 MHz, center1: 5775 MHz

FYI

RC3

Linux 3.18.17 #1 SMP Fri Jul 3 18:58:24 CEST 2015 armv7l GNU/Linux

disable the global rule when you put custom rules reffering to same service

Have been a long time lurker of this thread, since page 1!
I now have a question as I am porting support for this device to Gargoyle.

My understanding of "swconfig" was that it was supposed to be a universal tool where the output was stable no matter what target or device you are on.

On an ar71xx device, the command
"swconfig dev switch0 port 3 get link"
Gives the following output:
port:3 link:up speed:1000baseT full-duplex txflow rxflow

On this device however:
root@Gargoyle:~# swconfig dev switch0 port 3 get link
1000

To get an output similar to ar71xx you have to use:
root@Gargoyle:~# swconfig dev switch0 port 3 get status
link: up, speed: 1000 Mbps, duplex: full

Which as you can see is similar but still different (delimited by commas instead of spaces, for example)
Under an ar71xx device "get status" is undefined.

So is someone able to explain why these are different in this way? Am I wrong in assuming that swconfig' output is stable between devices?

Yes and no. There are a few standard swconfig commands/interfaces that will be stable from switch driver to switch driver. But you can also define commands specific to your switch/driver. In this driver things like "mask" and "qmode" are custom interfaces, and other drivers have plenty more.

Anyway, I was not aware that "get_port_link" was one of these standard interfaces. The driver I modeled the swconfig portion of mvsw61xx on (ip17xx) didn't use it, either. That explains our nonstandard "status" and "link" commands. The good news it's a very easy fix and I've already implemented it. I'll submit it later today when I have some time to look it over more carefully.

Thanks for reporting this.

What it looks like now:

root@OpenWrt:/# swconfig dev switch0 port 3 get link
port:3 link:up speed:1000baseT full-duplex 
root@OpenWrt:/#

(Last edited by leitec on 28 Aug 2015, 14:11)

I notice that when i add a new IPtables rule in the firewall. A simple "/etc/init.d/firewall reload" doest not load that rule in. I have to restart the firewall for the new rule to take affect.

Is that normal?

Fantastic
Thanks for taking the time to explain it to me and to bring it in line with the more common implementation.

Over the last few trunk builds i've noticed that when i log into the openwrt gui, the status page takes several seconds to load data. Almost all fields show "collecting data". In the past this used to be almost instant. Does anyone else experience this also?

I am with Linksys WRT1200AC v.1 with OpenWRT Chaos Calmer 15.05-rc3  r46163-
I have several problems, the first on the screenshot:

The temperature of the processor is, in my opinion, too high. I'm afraid that a fire breaks out, if I'm not home. If this is to be feared?

I have problem when I use samba. Before I used samba copy, after a restart of the router, so looks like the memory:

And so after copying a 7 GB file from the hard disk connected to the esata port of router via samba to my Windows 7 computer:

I think, there is a memory leak in samba package samba36-server_3.6.25-4_mvebu.ipk

The router will freeze later and then has to the outside and tuck the restart power supply

(Last edited by slan on 28 Aug 2015, 19:39)

Same here sometimes going to another tab and come back it will load normally.

@slan
That has been an ongoing issue for me also. I am using a wrt1900ac v1. I understand the caching but usually wireless will drop once the memory is used does not matter if you use samba or ftp. You can flush the cache by "echo 3 >/proc/sys/vm/drop_caches"
It seems like there should be a way to reserve say 10% of memory for everything else, but I have not found a way.

Yup exactly. Also sometimes its takes like 10 seconds for a tab to open up especially the system log. Even though its not long.

Don't forget to delete the stock cron job from RC3

Automatic fan control
https://forum.openwrt.org/viewtopic.php … 45#p287645

Hi,

I implmented that new fan control in my trunk build just now. I see that the PID got created. How can i verify that the script is indeed running? I dont see anything in the output of TOP or PS ?

luci > Status > Processes

Also  set enabled so it starts at bootup

luci > System > Startup > fan_control > Enabled

ps:

You can stop/start then check luci > Status > Processes

(Last edited by gufus on 28 Aug 2015, 22:13)

I had done it before. The screenshots have been done before, after I fan_ctrl.sh deleted from cron and restart.

This is my startup with all of the programs on the router:

(Last edited by slan on 28 Aug 2015, 22:49)

@gufus

i think its not working for me.

root@OpenWrt:/mnt/sda1# /etc/init.d/fan_control start
root@OpenWrt:/mnt/sda1# /etc/init.d/fan_control stop
start-stop-daemon: warning: killing process 2504: No such process

Even though it created the pid at /var/run/fan_monitor_pid

Thank you for the correction.

Rick S

(Last edited by RickStep on 29 Aug 2015, 02:00)

Gufus

Curious about this thread from Kaloz on May 7, 2015:

https://forum.openwrt.org/viewtopic.php … 68#p275568

It may have never been implemented.

Rick

Thanks for the help; I needed a new SSID for my router and with all the University Students around here RickStepIsAPrick is great.

Now my turn.

This thread was started on April 2014 by @glp and had to do with Belkin promising open source firmware which DID NOT EXIST.

Since then, early on Chadster766 worked to customize a driver trying to use the binary provided by Belkin and using firmware AA.  BB was never used (a few did) and openwrt skipped BB and concentrated CC. Kaloz and a few dedicated others have been trying for months to get a decent driver from Belkin and get help to TEST (which this group does not understand - despite repeated requests from Linux programmers).

Kaloz specifically ASKED that posters here USE the latest firmware and the latest driver to provide real current and important feedback for tomorrow; not from months old firmware and a really old driver.

THIS thread was started to get a working open firmware.  It started that way and has been steadily HIGHJACKED by everyone that has a personal agenda to get an application to work.  This should have been started in a NEW THREAD!

GET THIS and PLEASE GET THIS SOON.

UNLESS and UNTIL the firmware works RELIABILLY; you might get an application to work today but there WILL BE NO GUARANTEES that it will work after the next revision.

WE; ALL of us need to concentrate on a reliable released CC AND a working reliable driver from Belkin.

ALL other POSTS here should be moved to a new thread; Requested Application Support for the WRT1900AC v1 and let this thread deal with chasing add-on requests.

This is really simple.  If Belkin can't fix the driver; CC won't matter for the WRT1900AC and all of us will place our Belin 1900AC on the scrap pile.  AND all of the posts here chasing applications will be an utter waste of time.

Lastly; picking on me or my post about obsolete firmware and drivers means that you have NO IDEA about the importance of fixing firmware ONE step at a time.

There have been so many changes here that it is IMPOSSIBLE to filter which chance caused which effect.

Once CC is released AND Belkin steps up to the plate we should have a really stable firmware.

Then and only then should this post about open firmware be diverted chasing add-ons.

Rick S

@rickstep you haven't contributed one bit to this.  People are using and testing this router and actually contributing fixes.  You are not.  You need to stop making demands, especially since you're completely blind to the work being done that's documented here, and elsewhere.

p.s. get some tact, and stop whining.

@RickStep
I normally believe, live and let live, but contribute something  useful or GTFOH! unlike you I bought my router to learn, not to have it handed to me on a platter. When you quit learning, it is time to give it up! So someone likes an old version...So what? I flashed a new ver. of the trunk build bot it would not last more 8 min. using 33.8% on core #0  softirq and found out it is still the 10.3.0.8 replaced the mwlwifi.ko and my33.8% cpu0 went to nothing. This is to benefit all...... And to be a sheep........Let's just say I'm not going there. "Done feeding the troll"

One question though why has the revert not taken on the trunk?

The revert is only on the CC branch.  You can change to that if you want.  Trunk will always have the latest bleeding edge software, so that it can get tested and fixed.

(Last edited by nyt on 29 Aug 2015, 04:26)