A Wireless WAN Wifi annoyance (Mediatek 7620 + CCrc3)

Before i file it as a bug, i would like to ask others to see if they can replicate it
- on the same devices. NEXX 3020, and D-Link DIR-505
- on other devices with Mediatek 7620, and Atheros AR1311
- on completely different devices.  To see if they behave any different.

The situation:
Radio transmits on channel 6 in my case

Router connected to the net is the AccessPoint
WLAN SSID:TheNet

EDIT
Above is the existing router
and
Below is the OpenWRT router
/EDIT

Radio on channel:6
WWAN SSID:TheNet
WLAN SSID:OpenWRT 

All works fine until SSID:TheNet is not available

When you take the 'travel router'to another place and try to boot, OpenWRT does not find SSID:TheNet and as a result SSID:OpenWRT also does not seem to come up.

The 'travel router' is no longer reachable via WiFi.  So if you don't have a Cat cable in your pocket there is no way you can reach the router to reconfigure to connect to another WLAN. And that kinda sucks...

BUT:
When I add another SSID
SSID:WTF

Then it becomes a bit weird...   
Now all of a sudden de SSID:OpenWRT comes up. but the new SSID:WTF is not. And after a few minutes also SSID:OpenWRT disappears again. If I then try again, and add SSID:WFT2 nothing happens... 

With BarrierBreaker on a D-Link DIR-505 The issue seems to be almost the same, although on BarrierBreaker the WWAN Client SSID is automatically disabled when it can't reach the AccessPoint. Still the other SSID is also disabled. So the router cannot be reached over WiFi.  The DIR-505 only has 1 RJ45 So i wonder when i would have configured that as WAN instead of LAN if i then still could have access at all.  Or if it would stay in a semi-bricked kind of state until I'm near the last uses AccessPoint. Semi-bricked since you need a Cat cable to get access to the router, and when travelling you might not have a Cat cable in the suitcase.

Will also try this with the GL.iNet 6416 I expect the same, since it has the same SoC as the DIR-505.

What happens on other devices?

(Last edited by frietpan on 7 Sep 2015, 22:32)

@frietpan, I think you need to re-edit this so it's clearer.  Maybe a better title - WWAN Radio hangs all wireless access when no AP available.  Not sure it will fit

I also think that there is a mistake here:

You have 2 WLAN values, or just not following.  Just fix the above and add a note it was edited.

I had some weirdness with adding SSIDs to the single radio here: https://forum.openwrt.org/viewtopic.php … 25#p264725

mk24 has written about killing the wan side with a script here, so this is not entirely new.  You may want to research his posts.  https://forum.openwrt.org/viewtopic.php … 18#p272018

I will agree it's a poor software solution to a worse hardware problem, the single radio.  I have not interest in running a single radio.

Thanks,

I made a note hope that's clear enough.
Also thanks for pointing to those treads.

I've seen many more, but everyone seems to take it for granted.... I'm sure this is not how it supposed to work.
But it happens to all 3 my devices NEXX 3020, DIR-505 and the 6416.   

The 6416 with Barrier Breaker at least disables the WLAN But still you need a Catcable to be able to do anything when there is no WWAN.  It is what it is, and i can get around it. But i'm sure this is not what should be happening. 

Do higher end routers like for instance the Archer or Buffalo behave any different or does it affect every OpenWRT router?

tmo26 pointed me to the Bug list:
https://dev.openwrt.org/search
I'm searching if I can find ones that cover the same issue.
I already found a few that could be related. So I’m trying to figure out where it belongs.

I am afraid that the "business processes" have gotten a head of the hardware.  Until now, a router has always had a hard wired WAN connection.  It only needed one radio for WLAN.  Bridging has been problematic for a while now.  The hardware has not evolved to fit the new scenarios.

It's very hard to figure out most bug descriptions.

Issues that seem related:
https://dev.openwrt.org/ticket/20031 ' If any mistake occurs it will disable ap/sta iface altogether.'
https://dev.openwrt.org/ticket/13681  'no active connections in iw wlan..'
https://dev.openwrt.org/ticket/16543  'wifi configuration broken with 2 or more radios'

these two seem most related:

https://dev.openwrt.org/ticket/12000  wontfix????   <== wouldsuck!
https://dev.openwrt.org/ticket/12300  duplicate of 12000
https://dev.openwrt.org/ticket/12018 invalid/fixed ?  I don't understand 

Please note that these last three are 3 years old.  So is this a very old bug or a repeating bug?

(Last edited by frietpan on 7 Sep 2015, 23:50)

I see,
Does this mean it is best to not combine WWAN and WLAN for now?

Not all SoC's evolved in the same way. I wonder how hard it is to write code for this stuff.  I wish I could..

I consider it a limitation of the hardware design.

Software could be enhanced, but I do not consider this a bug.

This describes the issues with a radio's capabilities to run on both the client and AP sides.
http://wiki.openwrt.org/doc/howto/clien … modeissues

Variation of the same issue

i'll try to flash the D-link firmware. and see how that behaves with LAN and WAN on the same radio.

But what hardware design is lacking?
All hardware designs?

If the software can see that WLAN is on channel 1
then when you connect to WWAN the software connects to channel6 (in my case)  then how is it a hardware limitation?  I can see in the software that WWAN is on ch6. 
But ok, in the case where WWAN can't find any WLAN to connect to then there is no channel. And well
No channel is also a state   I don't see how software should not be able to figure that out. Now,  i must admit i don't know how hard it is to make that work. I just can't figure out how this can be caused by hardware.

Many Atheros based routers (Such as the D-Link DIR-505) have a repeater mode selectable by a GPIO switch. So D-Link must have build something that can do this using the Atheros 3133 SoC.

The Mediatek (RaLink) seems to be a bit different when it comes to  simultanious Transmitting and Receiving. And i haven't seen hardware designs based on the 7620 that have an option to work as a repeater, so for the Mediatek SoC it seems to be a different story. 

I'm also not saying that you are wrong. 

I just find it very odd that this is happening. 

So if this is not a bug, then what is it?  It's also not a feature... 
What can be done to clear up what is actually happening?
And what can we say in the wiki about it? Just to have clarity. 

Everyone (or at least several) who are trying to use nodogsplash with WWAN and WLAN seem to run into the same kind of issue. I'm not sure if it actually can made to work. I'm al new at OpenWRT and still have to learn everything, and I'm trying my best to figure out if this is the cause. Or, if I am the weaker link.

Isn't it possible to reconfigure radio0 to channel6 and then restart the affected processes?

I believe that your scenario is not a valid one, or I am wrong.  I do not believe that you can run a device with 1 radio on 2 different channels or with different channel widths or capabilities (b,g,n). 

Here I agree.  The software should be able to figure it out.  While I said it is not a bug, and I stand by that, I do not consider it a good design.  Just like my code for testing for a LAN connection may work, it's just not good design.  It will fail under some circumstances but works as designed.  It could be redesigned and written better (mk24 code).

Different chip sets have different capabilities, which may or may not be fully utilized in OpenWRT and may work under different limitations in stock form.   This is discussed somewhat in the bridged client mode issues pages here and other places.

I have no problem being wrong, but I do not think so.

As long as you on the same channel and use the same protocol all seems to work fine

radio0 on channel 6  using n protocol
WWAN and WLAN can coexist  Even Multiple WLAN's

On the NEXX I now have:
WWAN SSID of the router that i'm connected to
and 3 seperate WLAN SSID's
SSID1:OpenWLAN  unencrypted
SSID2:WEP WLAN WEP
SSID3:WPA WLAN WPA

So that works fine.

But if I switch off the Home router, so that the WWAN has nothing to connect to.
And then reboot the NEXX.
Then on boot the NEXX cannot connect
And as a result NON of the WLAN's are coming up.

THAT is the bug.

When you have a travel router this is a real issue when you don't have a Cat cable, or even worse, only a Android phone that only has wifi...

Then you are marooned.   No way to reconfigure your router. 

And it is also a bug because the router IS configured with in my instance 3 WLAN SSID's
When it boots and those WLAN's don't come up as configured i can't think of another way to describe it as a bug.

And as described in my first post there is some other weird stuff happening (when you add a SSID when WWAN is down sometimes another SSID comes available, but not the SSID that was last added.)

Unexpected behaviour / bug if you ask me.

The point you make that it works as expected well then I hope it will soon be upgraded.

I don't understand why you try to explain buggy behavior as expected behaviour.
Also since in another post you want to have an option that makes it more easy to configure. And I agree with that. Thing is this.  This 'expected' behaviour seems to be the one thing/feature that stands in the way to make that happen.

It's a pity that I don't have coding skills, but I do have some experience with betatesting.
So you may well be correct.

Maybe someone could point me to the code thin question? I doub't that I will understand any of it but having a look is the least that I can do.

I'm still convinced that this is a bug and should have some level of priority.  The bug that comes closest in the bugtracker seems to be very old and unfixable, although it doesn't describe the real buggy behaviour. And it doesn't address the issue that users can get locked out. 

So I'm not saying you are wrong, it's more like : I don't understand, but i try to make clear what goes wrong where it goes wrong, and what the consequences are for users.

Also because the 'travel routers' are very populair and becoming ever more populair. So more and more people will run into this. And from my point of view it is better to make that point clear to as many people as possible, also because my coding skills are not good enough to dive in on my own.

Yea i'm going to great lengths to make a point even when I don't understand the actual cause of it.
So I hope I did not offend you, if i did, my apologies, and feel free to pull my ear.  English is not my main language so maybe my wording isn't always the best.   

And thank you for your explanations I see there is much more to this then just buggy behaviour.

@frietpan - Not offended at all, healthy debate.  We just disagree on the definition of bug, but that's OK.

Create a new bug report and see what response you get.  Probably worth stating the the use case has changed.

Ok, cool

I hope my bug report can be replicated, I see small differences between the Mediatek 7620 and the Athereos 3133. It would be great is others could try and see if other chips have the same behavior or perhaps behave different. 

OpenWRT seems to be capable of doing this. And as long as it can connect to a WWAN then it actually works.

At this point I wish i had some coding skills, So that i could understand what is happening on the inside.

Bug is now listed here:

https://dev.openwrt.org/ticket/20475#ticket

I hope I didn't forget to mention anything.

Related topic:
https://forum.openwrt.org/viewtopic.php … 64#p292264

Bump. I have put OpenWRT on a HooToo TripMate Nano, and ran into this issue as well when I showed up to my hotel. I had to borrow an Ethernet cable and plug my laptop into the TripMate to get it to turn on wifi for the WLAN.

I understand that the use case generally was thought to involve a wired connection, but it just seems like a poor design choice to turn off all wifi if the wwan can't be found. Has there been any movement on this?

Thanks

(Last edited by gfunkdave on 5 Apr 2016, 05:43)

There are a few people trying to device a wifiMgr. But that seems to be stagnating a bit.

One thing to keep in mind is the wifi Channel WWAN and WLAN both need to be set to the same channel for this to work. If  the WWAN is not available then you can get locked out, so make sure you have a USB tty dongle for serial access