@dissent1: That's very interesting, but I'll have to admit I'm not sure how to get that into my build. Does the LuCI switch setup page still work with that driver? Not really a big deal, but more convenient.
And also, I'm using the 17.01 stable branch and not master (wifi is useless in master for me), which I guess is also troublesome.
Is your version 17.01 also including the patches of the official stable 17.01.2 and meant to be the daily driver?
I only used master so far and want a stable base. What should I go with?
No, it's a different conception, you don't need swconfig to configure the switch, you are getting native Linux tools instead. Each port is represented in kernel as a seperate interface, so you can do whatever kernel allows you to do with it.
Nope, only k4.9+
[quote="dissent1, post:347, topic:316, full:true"]
No, it's a different conception, you don't need swconfig to configure the switch, you are getting native Linux tools instead. Each port is represented in kernel as a seperate interface, so you can do whatever kernel allows you to do with it.[/quote]
Ok. But I guess that if master will be switching over to this new driver, there will need to be LuCI support for configuring it (VLANs and such). With the current state of affairs, I guess there isn't support in base UCI either? So any config needs to be manually scripted for now?
Did you test this yourself? Have you made a build which includes this new driver?
No need for that, it's native Linux tools - you just add interface with '.vlannumber' in luci as usual i.e. lan1.30 - it's lan port 1 tagged with 30 [quote="mroek, post:348, topic:316"]
Did you test this yourself? Have you made a build which includes this new driver?
[/quote]
Yep I'm running it for a pretty while
Ok, thanks. Sorry for being dense here, but to enable IGMP snooping on the switch, would you use sysctl for that, then?
In theory yes, but I don't need multicast to be forwarded, so I have not tested it myself.
Hi Dissent, I've been looking at your repo for a little while, what other goodies do you have in there, might attempt a build later
If the default is that IGMP snooping is off, then you're probably already having multicast forwarding enabled. But as long as you don't actually use multicast, it doesn't really matter. Could you take a peek in your router, and see what the default is?
Since I'm rather, shall we say inexperienced, in the build system, can I ask how I would go about to apply the driver commit from your repo to my own build environment (based on master)? Can it be downloaded as a patch and then applied, or do I have to use git to cherry pick that commit from your repo. Again, sorry for being dense, but hopefully I'll improve. And @hnyman, if you think these questions are inappropriate in your thread, I apologize.
Yes.
any github commit can be downloaded just by adding ".patch" to the and of it. Download it with wget,curl or ...whatever, then just apply the patch.
web page: https://github.com/dissent1/r7800/commit/fd065e652c2d49db3fab42f800ff9002ce4993fa
patch: https://github.com/dissent1/r7800/commit/fd065e652c2d49db3fab42f800ff9002ce4993fa.patch
You can first test it with "dry-run" quite normally, so that you see that it applies without errors. (run patch command from buildroot root)
patch --dry-run -p 1 -i patchname
(And I think that original for that is actually in blogic's staging tree (but dissent's version might have additional fixes, I haven't checked)
https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/qca8k
Yeah, you should take this kind of generic discussion to the R7800 exploration thread Netgear R7800 exploration (IPQ8065, QCA9984) (if the topic is R7800- or ipq806x-specific), or even better, start a new thread about IGMP snooping.
Two main reasons: this off-topic discussion clutters this topic, and even worse, you don't reach the attention of people who really know about IGMP snooping (as they likely are not interested in my R7800 build).
Ok, thanks. I'll stop polluting your thread. As you know, I did start a new thread about this issue, but I guess the people that really could answer is too busy to do so.
May I ask one more dumb question, but this one is related to your build environment:
I have used your script to recreate your build environment, and then made some minor customizations for myself (basically just creating my own .config.init-file with my preferred packages). I can then update and make as new commits are made, but if you make changes to your patches, and I want to stay current with those, how would I do that? Is the easiest method to just start over from scratch? Reversing the original patches and then reapplying the new ones is perhaps not a good idea?
There is no really easy way.
Maybe a good starting point is to store and compare the patch files that I publish along my build. Then you can make a diff of the old and new patches and see if anything has changed between the releases. I tweak the code pretty seldom, so usually there are no changes. If you spot changes, it is a question of the easiest method to apply them.
E.g. an one-line change to some script, might be easiest to edit by hand.
Also added new files / scripts are rather easy to spot and apply.
But a more complex change may require more work. If you have not touched the same files, reverting the original patches and applying the new ones may be viable.
If you have edited the same files, in a complex way, it may easiest to start over, and then first apply my new patches and then repeat your own editing.
If you can make diff patch out of your own changes, that will ease the updating.
Hi, yes works on 17.01.2, but if I create a vlan same layout as your firmware, eth0.1 by changing eth0 to tagged, then jumbo frames stops working and mtu is 1492, any ideas?
I ran into a (very) minor issue, which I find a bit curious. In the interfaces statistics plugin I had defined br-lan and eth1.11 enabled for monitoring. Then at some point I removed eth1.11 altogether (did some re-plumbing of my VLANs), but it still appeared in the graph for the interfaces (just with no data). Then I went to the config page and made a new selection of interfaces to monitor (and eth1.11 was not listed in the dropdown, since it doesn't exist).
Now comes the slightly curious part: There is still a graph for eth1.11 (with no data), even though there are no traces of eth1.11 in the config files. I tried restarting both luci_statistics and collectd, but no change.
So, where does eth1.11 come from? Rebooting the router will probably fix it, though (haven't done that yet).
@hnyman: It seems that removing interfaces from monitoring always requires a reboot to become effective. Removing an interface in the setup page doesn't remove it from the graphs. Have you observed this?
Which graphs??? Nlbwmon? I guess that it does not monitor network config changes, but I haven't tested that, as my own config is rather static.
The graphs for interfaces under statistics in LuCi. Your default config includes just br-lan, but try adding one of the other interfaces under statistics/setup/network plugins/interfaces. Afterwards, try removing it again. It is being removed from the config, but the graph itself doesn't go away.
Yep, because the graphs are based on the data in the rrd database. Config change does not remove the already collected data, so it gets shown.
Ah, ok. Manually deleting the rrd database directory for the removed interface is of course possible, and that removes it from display also.
Do you typically post here when new versions are put on your DropBox site or do I just need to monitor that site?
Also, how would one reflash to the stock firmware from your build? Just flash the Netgear .img file from the LuCi GUI?
Thanks for the build. About to flash it for the first time from stock, wish me luck!