Gargoyle-ispy 2013-November-1.7z

[Garghoul]

The real work is done by others, I just push a script.
[........]
The people doing the real work I suspect would get a little annoyed at me getting praise for their work.

Well, then I simply extend my gratitude to everybody involved, making those 'unofficial' updates happen

Unfortunately though, I am still having quite a few weird WiFi problems, I can't really make sense of and therefore am asking for help from people, much more knowledgeable in that area, than I currently still am.

Setup:
Netgear WNR2000v3 (F/W upgraded from V1.0.1.26 to V1.1.2.6, just to make sure) is the AP/WAN Gateway (IP: 192.168.1.1), connected to a cable modem.
Buffalo WZR-HP-G300NH (1.5.X (Built 20131030-1936 git@8a56193); WAN IP Address: 192.168.1.11) connects to Netgear in Wireless Mode: AP+Client (LAN IP Address: 192.168.11.1).
Connect Via: Wireless (DHCP | Static IP)
Access Point SSID: Gargoyle (broadcasting SSID: disabled)
SSID Joined By Client: NETGEAR

1.): multiple times per day, traffic between the Buffalo and the Netgear gets interrupted, even though doing a Connection->Basic: Re-Scan shows, that the Netgear SSID is still around with a signal strength usually between some 47...56% and still using the same channel as before.
AFAIKT, there is no difference in using DHCP or connecting via Static WiFi IP to the Netgear.
I also can't notice any difference of the setting: "Wan Ethernet Port: En-|Disabled"
I can ping from WiFi-LAN both sides of the Buffalo (168.1.11 & 168.11.1), while the Netgear (168.1.1) remains silent.
Q1.1): [x] Drop Ping From WAN Side: Why do I still get a WiFi response from 168.1.11? Or does this setting only relate to the Ethernet WAN port?

A "Save Changes" from the Connection->Basic or ->Routing screen, usually re-establishes the link, if not, I have to Reboot.
Q1.2): Why doesn't Gargoyle reconnect automatically, when the IP connection breaks?
Q1.3): Is there another way to kickstart the apparent broken WiFi link between the Netgear and Buffalo through the WiFi LAN side, other than as described above?

2.): After doing a "Save Changes" as described for Q1.2) it occasionally happens, that the Buffalo's radio seems to remain silent, since it doesn't show up in any iwlist scans from 2 laptops or in any available-WiFi scans of 3 Android smart phones.
Q2): shouldn't the Buffalo's radio work all the time as AP for LAN WiFi clients, no matter what is going on with the WAN WiFi link between it and the Netgear, or is there a dependency?

3.) During the last 2 nights the temp dropped slightly below freezing and the Buffalo is mounted to an outside wall inside a wooden garage.
Q3): Is there anything known about special temperature sensitivity of the WZR-HP-G300NH, causing it to have its radio silenced, when "Save Changes" as described for Q1.2) was necessary?
With last night having been the colder one (-6C), the whole thing must have 'frozen up', when I additionally made an actual change in the static WAN IP from 168.1.9 to 168.1.11 @ around 1:30h, when the IP flow got stuck once again, since neither a scheduled Reboot @ 5h this morning was performed, nor was I able to connect to it via Ethernet.
I had to pull the power plug on it, to force a hard reset. Really strange. Just a coincidence?

Now it is up to you, smart readers, to flood me with your expert suggestions and explanations

[buddee]

Now it is up to you, smart readers, to flood me with your expert suggestions and explanations

You must not have read the post of mine right before yours that is on previous page, the client+ap problem still exists with the same errors that all of the other test builds exhibit.

The only suggestion or remedy for this is to roll back to a build that has a functioning client+ap mode - for me on a wzr-hp-g300nh - that build was 1.5.6 but the downside of that is the thru-put over wifi is better with the newer builds. 1.5.6 works with client+ap but not as great wifi as the newer builds. So hopefully this gets fixed.

[Garghoul]

Thanks, buddee, I actually read your post with great interest. It is what led me to and give the current 1.5.X a try, but I failed to connect the dots of your webcam problems likely having the same root cause as my WAN, and to a lesser degree, the LAN WiFi links.

- Does the dmesg log excerpt which you posted, come from the router or the connected computer?
If it is the router, how do I get there to a terminal? So far I am only accustomed to talk to it via WiFi through the GUI.

- For the time being, if the .11g/n throughput can manage up to some 10Mb/s reliably, that would be sufficient for my current use case and I would like to give it a try, to see if that would eliminate my disconnect problems as well.
So, I suspect the 1.5.6-ar71xx-wzr-hp-g300nh-squashfs-sysupgrade.bin won't work to roll back from the current 1.5.X and I don't see a factory.bin build.
- Do I then need to use the wzr-hp-g300nh-squashfs-tftp.bin instead and learn about doing it via tftp?
- Can this then be done over a LAN side WiFi link, or do I need to have access to the router and connect via Ethernet (not impossible, but rather inconvenient due to the routers location)?

- Does 1.5.6 also already support NTFS formatted MSDs on the USB port? That actually was the whole reason, why I was looking for a better featured alternative to Buffalo's stock offers.

- Anything else, that I might have missed?

[Garghoul]

Nothing? Really? No one can help me out at least with one or another issue?

[buddee]

You seem to have 2 issues in your previous post..

Your first issue: will the sysupgrade.bin work for roll back? I didn't have any problems using the sysupgrade.bin to roll back with.

Your second issue: Does 1.5.6 support NTFS thru the USB port? That i can't tell you, i use the wzr-hp-g300nh as a simple repeater with no other bells or whistles, i don't use the USB port on the unit to be able to tell you whether or not it is supported.

[Garghoul]

You seem to have 2 issues in your previous post..
Your first issue: will the sysupgrade.bin work for roll back? I didn't have any problems using the sysupgrade.bin to roll back with..

Thanks a lot, Buddee, that is exactly what I needed to know.
Then I probably can to get to work on the roll back over the weekend.
Only other thing: in your previous answer you mentioned this older build having slower WiFi throughput. From your observations, will it still meet my current, rather low data requirements?

Your second issue: Does 1.5.6 support NTFS thru the USB port? That i can't tell you, i use the wzr-hp-g300nh as a simple repeater with no other bells or whistles, i don't use the USB port on the unit to be able to tell you whether or not it is supported.

Good enough, then maybe someone else still using that version or having used it back in the day in this specific NTFS MSD on the USB port use case can jump in and help out?

[Garghoul]

Well, downgrading to 1.5.6 turned out to be rather disappointing. Even though the feeding Netgear WNR2000v3 and my Buffalo WZR-HP-G300NH again connected nicely in AP+Client mode, they didn't actually 'talk' to each other at all.
No IP traffic whatsoever, no ping, no ntp, no DHCP exchange - it also didn't work when providing a static IP adress.
So, this exercise was a very frustrating, total no-go for me.

But, on the bright side, after reverting back to 1.5.X (Built 20131030-1936) and the discovery and installation of the 'Ping Watchdog' plugin, set to a reasonable short time interval, seems to be an acceptable band-aid solution for my current use case for right now, until the WiFi firmware part improves hopefully soon.