@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.
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.
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]
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.
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?
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?
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.