Yes. Please don't explain a point, the UCI and LuCI are the same.
Make config on LuCi
Paste UCI config like everyone does
That's how I verified you in fact were discussing the same config interface mtu config (just to admit yo have to set MTU in config device). I acknowledge a MTU config in the interface, so if you say you set it on the Device page, I agree. I can't guess.
No more gotcha games.
Since you can "verify" your issue and I assume screenshot and explain it and show configs too (and not question the person if they are in fact the config) - you would be better suited to do that.
No, they don't. Luci doesn't expose lots of advanced or dangerous option. This is one of those. Only one MTU should be exposed. The one which actually changes interface MTU.
We discussed not exposing MTU to LuCI (period), but now you seem to be discussing the MTU PPoE interface MTU is wrong anyways. As it appears in Interface, when it needs to be in device?
Again, I'm not sure, I assume that's what you mean. If so, feel free to make that report.
You use a method where you ask a whole World about a bug you saw first, nit pic on configs, etc. "Convincing" may be the wrong method - or the wrong definition here.
When making the report on GitHub, I would just show all my evidence and steps (e.g. with no invalid ellipses in the configs). Then nobody had to guess, they just merely fail to reproduce.
And in someone else's thread (moot "why would ", etc.).
You may wish to make a thread specific for PPPoE users that have Ethernet. But nonetheless - if you say config device name pppoe-wan works and config interface pppoe-wan doesn't, I believe you and I now understand.
The answer is complicated and depends on whether you have the config to access the modem web interface (i.e., another interface with the static protocol on device wan) or not.
The option mtu '1508' on config interface says: set the MTU on the parent device (wan) to 1508 if possible, then negotiate that minus 8 (i.e. MTU=1500) on the PPP tunnel if possible. If the PPPoE interface is the only one that is based on the wan physical interface, it is supposed to work. It is known not to work if there is another config interface on the same physical device (because it by default implies MTU=1500 on the same device and thus conflicts), and then we might need either the option mtu '1508' in config device to resolve the ambiguity or the same option in all other interfaces that use wan.
I use the second solution (option mtu '1508' on both config interface stanzas, no config device at all except bridges).
Hi @pythonic , apologies for the delay in getting back to you! I was finally getting routing to raising an issue on Github for this and was wondering if you could point me at the code you were looking at so I could reference it?
@dys152 I'm working on a patch which I hope to have testable in the next few days, but other than checking I can set the MTU I won't be able to test its operation.
Are you able to build a test image from a github checkout and test it?
Hi there,ah excellent, thank you! I have never built an OpenWRT image from source but will take a look at what is involved (I have built similar code on other projects). Am happy to be a guinea pig anyway
Ok, I've tested a patched build on my 7530 and can change MTU to 1508 without error, but as noted I can't test actual traffic as my connection is IPoE rather than PPPoE and 1500 bytes is the max MTU for it.
For convenience I'd suggest creating a files subdirectory in your checkout and populating it with the DSL firmware per the 7530 installation guide so that it gets built in to your images.
I use the following very basic diffconfig file for my 7530 - you can save some mucking around in menuconfig by saving it as the .config in your checkout and then run make defconfig to get a usable .config for building:
If you want to add packages, run make menuconfig after make defconfig.
I'd suggest starting by building either main or the 23.05 branch from a normal openwrt checkout and get comfortable with building and running an unpatched image; once you've got the build environment sorted, you can then build from my patch branch:
If that works for you, I'll create a pull request to see whether the OpenWrt devs will accept it. The patch applies to 23.05 cleanly as well as main, so I'd be hopeful for a backport.
Thanks @pythonic, realistically it will be Monday before I get a chance to look at this but will feedback after that. Also thanks for the links and tips.
Have built the image from your branch and my Fritzbox is booted, however can't get the broadband to sync, reverted to stock and same issue (i do have firmware on there its loaded and DSL interface is available). However i think this is self inflicted as i backed up my "working" config but think i may have messed with it over the Christmas period and forgot to try it out by bouncing the router. Will be Thursday before i am allowed to take the broadband down again(!), in the meantime have reverted my Homegub 5.0a again.
Hi there, I've also been away unexpectedly, have set aside some time Tuesday to look at this so should have an update after that. Sorry for the delay, I do really appreciate your efforts here!
By means of an update, there is either a hardware issue with my router or I'm doing something basically wrong as not getting sync on the VDSL any more (it tries and fails: L3 - No Power). I am currently trying to revert to non-OpenWRT code but the bootloader is using 192.168.1.1, rather than 192.168.178.1 that the AVM recovery tool expects! The bootloader IP address thing is referenced on the 7530 OpenWRT install page so whether it's certain versions of it I don't know. Currently fighting with double NAT on a cisco router to try and get to a point where I can recover it as would like to know of DSL is working with the OEM software.
I am going away for a week on Friday so it may need to wait until I get back to bottom this out.
