Gargoyle Forum

Did you preserve settings on upgrade?

Waterspuwer wrote:I'm unable to remove 1.10 from plugin list after adding 1.11-rc4 path:



My router now has this uptime
5 days, 3 hours, 51 minutes
It's been solid as a rock with the last RC4 build (what changed with this new RC4 build?).

Wi-Fi channel settings are still semi broken though. Wi-Fi will not turn on after reboot on 'higher' channels. See RC3 thread for the details.

Waterspuwer wrote:I'm unable to remove 1.10 from plugin list after adding 1.11-rc4 path:



My router now has this uptime
5 days, 3 hours, 51 minutes
It's been solid as a rock with the last RC4 build (what changed with this new RC4 build?).

Wi-Fi channel settings are still semi broken though. Wi-Fi will not turn on after reboot on 'higher' channels. See RC3 thread for the details.

If you add a source that is at the Gargoyle or Openwrt sites, it is considered “preset” and unremovable.
You could manually remove the source from /etc/opkg.conf

I will check your behaviour with wifi, but I’d love to see any relevant logs. I’ve never seen this before and don’t think I’ll be able to reproduce, but I will check.

If you could also private message me a copy of your /tmp/cached_basic_vars that would be helpful.

As a follow up to your wifi problem, i have confirmed all behaviour is as expected on my device on 2.4GHz band.

If your regulatory region does not allow channels 12, 13 and 14, they of course will not start.
You cannot set a 40MHz+ channel above 7 (9 if 12 and 13 are allowed).
You cannot set a 40MHz- channel below 5 or above 13.
As stated previously, 40MHz channels are not guaranteed to be initiated, and in this case a 20MHz channel should start instead on the requested channel.

If your particular device is misbehaving, I would need to see the details i mentioned in my last post in order to investigate possible causes.

Eric...

Some observations...since x86 1.11_RC3 was released it appears that port forwarding on x86 platform is possibly broken. I cannot reach my LAN devices from remote port 80 to local port 3389--Remote Desktop.

Next, on my Linksys WRT1900AC device. The gargoyle_1.11.x-mvebu-cortexa9-linksys-wrt1900ac-squashfs-sysupgrade. Since RC1, it seems that if I try to change my 5Ghz channel to anything except channel 39, it shuts off. LED turns off and nothing on 5Ghz is being seen by the devices, even though the config page shows it is on and working.

Please advise if you need further documentation, screen shots, etc.

Thanks,

Andy

https://github.com/ericpaulbishop/gargoyle/pull/781

Wifi driver changes down the bottom.

RC5?

bluegravy wrote:Eric...

Some observations...since x86 1.11_RC3 was released it appears that port forwarding on x86 platform is possibly broken. I cannot reach my LAN devices from remote port 80 to local port 3389--Remote Desktop.

I made a change to try auto configuration of the WAN and LAN devices. It is possible that the roles of the ports has reversed between RC2 and RC3. Have you checked this? The change shouldn’t break port forwarding itself though.
If you have a /etc/config/network file from RC2 and RC3/4 that you could provide for me to compare that would be beneficial. Please be mindful to remove any passwords or identifiable information.

Next, on my Linksys WRT1900AC device. The gargoyle_1.11.x-mvebu-cortexa9-linksys-wrt1900ac-squashfs-sysupgrade. Since RC1, it seems that if I try to change my 5Ghz channel to anything except channel 39, it shuts off. LED turns off and nothing on 5Ghz is being seen by the devices, even though the config page shows it is on and working.

Please advise if you need further documentation, screen shots, etc.

Thanks,

Andy

You shouldn’t be able to select channel 39, it isn’t a channel we make available. Can you confirm exactly what you are setting there? A screenshot should be fine.

ispyisail wrote:https://github.com/ericpaulbishop/gargoyle/pull/781

Wifi driver changes down the bottom.

RC5?

Dropping all references to madwifi to cleanup the firmware. It is no longer required.
I don’t know if I’ll do an RC5 at this stage, we might just get to a proper release. Just need some more feedback on this release first and then I’ll talk to Eric

ispyisail wrote:Did you preserve settings on upgrade?

Lantis wrote: If you add a source that is at the Gargoyle or Openwrt sites, it is considered “preset” and unremovable.
You could manually remove the source from /etc/opkg.conf

I will check your behaviour with wifi, but I’d love to see any relevant logs. I’ve never seen this before and don’t think I’ll be able to reproduce, but I will check.

If you could also private message me a copy of your /tmp/cached_basic_vars that would be helpful.

Yes, I preserved settings. But plugin sources are not remembered. Shouldn't preset only check whether the sources are actually preset for 'new' builds? I would expect anything you're adding yourself to be removable.

I've sent you the cached_basic_vars file.

Lantis wrote:As a follow up to your wifi problem, i have confirmed all behaviour is as expected on my device on 2.4GHz band.

If your regulatory region does not allow channels 12, 13 and 14, they of course will not start.
You cannot set a 40MHz+ channel above 7 (9 if 12 and 13 are allowed).
You cannot set a 40MHz- channel below 5 or above 13.
As stated previously, 40MHz channels are not guaranteed to be initiated, and in this case a 20MHz channel should start instead on the requested channel.

If your particular device is misbehaving, I would need to see the details i mentioned in my last post in order to investigate possible causes.

Channel 12 and 13 are allowed in The Netherlands (1-13). For 5 GHz channels 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140 I think.

It's an odd issue. It works if Wi-Fi has at least been started correctly once. For example, if I put it on 13 with channel below, it's working after I've used channel 6 for example. But on reboot it will not start Wi-Fi until I switch to a lower channel and then back to 13. If it's not started, it will not start if you modify channels until you reach a channel that can start (so if you're on 13, then try 12 (without reboot), then 11, etc). I hope this helps, I tried my best to explain it.

Sure, it might be a bit of a strange assumption to make, and maybe even “lazy coding” but it works. There’s no reason for you to add any repository pointing to the Gargoyle site that isn’t there by default. Openwrt the argument could be made, sure.

Nothing out of the ordinary in your settings.
Could you force the problem with a reboot, and provide a logread and dmesg immediately after the problem occurs please?

Hi I flashed to my wrt1900ac-v2 and QOS will not turn off. It is set up as a repeter bridge. When I go on to the qos upload page and untic the enable qos tick box it takes about 10 seconds for the box to untic and then after clicking on the save and apply, the page refeshes and the enable qos for upload is stil ticked. Same gos for the QOS for download page. I will try and get the time to reflash at the week end and remove all config files. When I flashed I did a dirty flash over RC1. Thanks for all the hard work that has gon in to this build.

I think that all the things that have bin made in to plugins for the low flash routers should be made in to plugins for the bigger routers to. When using my wrt1900ac-v2 as a bridge I don't need any of the QOS and things. I don't like having the webcam, vpn and tor stuff built in either