If you check the manuals specifications I believe you will find that the TM05 and TM06 both carry the MT7620 family chips.  This firmware will not run on these. 

There are projects that do use this family of silicon.
http://wiki.openwrt.org/toh/views/toh_e … mp;dataflt[Platform*~]=mt7620

I will suggest that you go here and start by adding the device to the ToH and then create a Device page with what ever data you can scrape together.  http://wiki.openwrt.org/doc/howto/adding_to_toh   You may also wish to start a a new Forum Post for one or both devices.

Not sure what you are trying to do.  Sounds like the package management might be your problem.  Could you describe what steps you took to get to CC RC3? 

For me on my TM02, after downloading and installing openwrt from the wingspinner files, I just used Luci to install (not saving the current configuration) the following:

https://downloads.openwrt.org/chaos_cal … pgrade.bin

After that, just ssh into the hootoo and issue the following command lines:

opkg update
opkg install openvpn-openssl

Of course, configuring OpenVPN is another challenge, but let's get you this far at least.

Let us know how you fare.

(Last edited by klaberte on 10 Sep 2015, 03:14)

Hello! I'm pretty new to the whole open wrt world but consoles and line commands are my friends, so I guess I can survive.
I received a faulty TM-02 (kept disconnecting after few minutes, than needed to rest powerless to be able to connect again, no reset available). I tried updating the firmware, but instead of fixing I seem to have bricked it (steady blu light, no wifi).
Luckyly my seller sent me a replacement without asking me te return the faulty one so I was wondering if I can experiment a bit with the bricked one before dumping it but I need I few info: given that the unit is bricked, if I solder the USB-->serial cable, will I be able to tfpd it? Or should I try the flashing clamp? I have none of them but I can ask some friends or buy one just for playing around. Tftp seemed easier to me, but it's unclear to me if the bootloader will answer once I solder the four pins with a bricked unit. Obviously, since the unit was faulty as it was sold, I am aware it could be an hardware problem and flashing the chip wont help me at all... but it's going to be dumped so I would give it a try just for learning.
As a side note, I was wondering why I cannot connect to the bootloader to upload the file from the ethernet as suggested http://wiki.openwrt.org/doc/howto/generic.flashing.tftp ?
Thank you for any suggestion,
Lila

(Last edited by liladude on 10 Sep 2015, 05:02)

Has anyone been able to restore the factory HooToo firmware after loading OpenWRT?  Mine is a TM-03 running r44945.  I was trying to rescue the router after loading HooToo firmware for a TM-04 but OpenWRT seems to be the point of no return.

If anyone has been able to do this without mods or cracking it open I would like to hear how you got it restored.

I have another question.  Does anyone know where I could get the contents of the original mtd partitions?  I only have files for "bootloader", "kernel" and "rootfs" from a HooToo firmware update image.  It seems those are not enough to rescue my TM-03 and I might also need "params", "user_backup" and "user" to reflash the "firmware" mtd.

Page 2 has a post from the OP to concatenate the files to build the "firmware" partition for tftp upload.  It is the same process I used to install OpenWRT in the first place but now I want to go back to original firmware.

If I can't get the files then I might buy a TM-02 and pull the data from that device to rescue the TM-03.

Anyone had any luck getting pptp to work? I installed the latest sysupgrade and the relevant pptp packages, but after adding the pptp connection and login details it never connects...

Hi, noobsauce here.  First, thanks WingSpinner for putting this together, and also thanks to RangerZ who suggested CC RC3 which I installed the other night (15.05-rc3 r46163).  I hit a roadblock trying to get OpenVPN set up prior to that.  Since then I have been banging my head trying to get AP+STA to work with the HooToo TM02.  I want to use the TM02 as a OpenVPN client, and have it connect to a wireless WAN (STAtion) and wireless LAN (AP).  I think that the out of the box firmware does this so I am pretty sure it is possible.  I've seen some posts indicating that the chipset can support it, but the "iw list" command does not show any P2P modes (which I read would also indicate driver support for the AP+STA modes).  I've seen some strange behavior when trying to use STA+AP on my TM02, basically it only works when the WAN (STA) side is using an open (no encryption) AP, and the LAN side (AP) only comes up if the WAN side (STA) is able to come up.

So I guess my question is, is AP+STA possible for the TM02 + OpenWRT, and has anyone got that working (and if you are feeling generous, maybe point me in the right direction)?

Thanks!

For the moment put OpenVPN aside.  With 1 radio in the device you must set the channel, width and bands the same on both sides.   I am not sure if you need the security params the same, but mine are.  The key can be different.   If your router is set as a Router and not AP, then you should pretty much be able to connect.

Search the wiki for bridged mode client issues.  It's basically the same problem.  To make this an AP your need relayd, but we want a router for OpenVPN. 

In practice, you do not know what channel the AP/Wifi your HooToo client will need to connect is on. This means you will need to match the the HooToo AP (LAN side) to that, which also means the LAN client will also now need to be reconfigured each time to the HooToo AP, if the WAN side AP is on a different channel.  This will generally require a cable on the LAN side, as when the WAN side can not find it's AP, it crashes both sides of the wireless. 

See frietpans https://forum.openwrt.org/viewtopic.php?id=59448 and others.

I found the constraint too difficult for use as a OpenVPN client and have given up USB storage for a second radio (EDIMAX 7811) on the USB which works completely independent of the other radio.  Slightly slower but I get a usable OpenVPN (TAP).  I should note that this is not a HooToo issue.  All routers have the same basic issue with 1 radio.

IdiotProof, RangerZ (as usual) gives excellent advice.  Let's clarify your intention in order to give you what you want.

Is your primary goal to create a travel router, where the network providing the internet changes frequently, or are you trying to set up a permanent repeater, e.g. for your home?

Ah that explains the strange behavior, thanks!  I was thinking I would be able to at least get in from the LAN side and configure the WAN parameters, but I can see now that will not work without a wired LAN or very carefully considered pre-configuration which is not practicable in the real world (moving from place to place).  The stock firmware does do AP+STA from what I recall, which is what drove me to try it (only used it once with stock fw). 

Something that reading that thread jogged in my memory was that the WiFi WAN (STA) would not work with encryption enabled (it only worked when used on an open network) - and in fact when I configured the WAN (STA) with encryption to test, I thought I would be locked out when the WiFi LAN (AP) did not come up (blue light went out after bootup) - until I turned off encryption on my guest Wifi on my home router which I had been using to test the HooToo WiFi WAN (same SSID and channel were left in place) - then the HooToo connected to the guest network as it's WAN, and I was able to get back in (this while the HooToo was still configured to use encryption on the WAN (STA)).  I had also tried "auto" for the channel with the hope that the WAN (STA) would select the appropriate channel and LAN side AP would just use that, which seemed to make no difference (it worked, but did not resolve any of the other issues).

But backing up, and to answer Klaberte's question, my planned use for the router was as an OpenVPN client which I could use on the road when there is only WiFi to connect to (and since my laptop has only WiFi, I would need to use wireless for LAN and WAN).

It sounds like to get where I need to go, the use of the WiFi USB dongle is probably something I need to explore due to the condition explained by RangerZ above (single radio being impracticable to get working with both LAN and WAN utilizing it).

I know this works: http://www.edimax.com/edimax/merchandis … ew-7811un/ and is about $10. 
https://forum.openwrt.org/viewtopic.php?id=58548

I was able to reflash my TM03 back to factory firmware using the mtd partitions from a TM02.  Now I have the TM03 back the way I want it and a TM02 to play around with.

The bootloader recovery mode works well once you have the right files.

This question has come up a few times.  Could you post a more detailed howto, as well as the required files, to allow people to get back to their original firmware on the hootoo?

Let me try to explain what I think is going on.  When the hootoo (and perhaps other single-radio OpenWRT devices) is configured to boot up as a travel router, i.e. with both WWAN and WLAN activated (behind the scenes, the WWAN is likely using the default radio instance, and the WLAN is using the virtual second instance), and the WWAN doesn't connect (e.g. because you have changed hotels, and it has a different SSID), well, then the virtual SSID doesn't come up, and you cannot connect wirelessly to the hootoo to reconfigure the WWAN.

The reason the same hardware works as a travel router with the default firmware is that--this is my assumption, having not been able to review the OEM software--when the device boots up, it always boots up into a mode where both the wifi and ethernet are bridged, and the wifi is configured to be a WLAN.  This allows you to connect on the LAN side (either wirelessly or via ethernet), search for a SSID to serve as the WWAN, then restart the wifi connection (not the whole router) into WWAN+WLAN. 

Using the pure OpenWRT build, I'm sure something similar could be done via scripting, but I have never tried.

(Last edited by klaberte on 16 Sep 2015, 15:51)

Before purchasing additional hardware, please consider your options.

Yes, RangerZ reports good luck with the hootoo+edimax solution. 

https://forum.openwrt.org/viewtopic.php?id=58548

I have tried the same and, while I got it to work, I am not satisfied with the throughput performance.  Both RangerZ and I have found that the throughput of the hootoo + edimax (on different channels) is worse than using just the hootoo (single radio, so single channel) for both WWAN and WLAN (using VSSID).  He is satisfied with his performance, mine is worse and not acceptable for me.  (In fairness, I have not done detailed troubleshooting, so this may be user error)

Instead of spending $10 on the Edimax, you could spend $20 on a second hootoo.  Connect the two hootoos by a very short ethernet cable, and now you have two fully independent wifi radios, which can run on different channels, use different encryption, etc.  Not as compact as the Edimax, but with some two-sided tape and a short ethernet cable (and an extra USB charger cable), you'd still have a pretty compact kit.

Alternatively, you could buy a GL-iNET for about $24 (on amazon), or get the one with an external antenna for a few dollars more. 

https://forum.openwrt.org/viewtopic.php?id=59101

Here are some advantages I see for the GL-iNet over the hootoo

1. The OEM firmware is based on OpenWRT, in fact you can get to the OpenWRT Luci just by clicking the "Advanced" button in the OEM configuration page.  This allows all the configuration options of OpenWRT with the simple setup (when that's all you need) of OEM firmware.

2. The OEM firmware allows you to configure your 6414 using your phone (it has a nice, lightweight app that simply addresses the travel-router configuration issues described above).

3. You can easily update to the latest trunk of OpenWRT (but you loose the OEM easy configuration app), and just as easily go back to the OEM firmware.

4. When it comes time for you to setup OpenVPN, I have gotten much better OpenVPN performance out of the 6414 than the hootoo (YMMV).  I am lending out my 6414 right now, so I can't do a solid benchmark, but I think the 6414 has more horses under the hood.

5. It has both WAN and LAN ethernet ports, just in case you decide to start carrying ethernet cables in your kit.

Good luck!  Let us know what you decide to try.

@klaberte, well said, but still not sure how the APP address the issue of Hotspot (WAN side) channel vs LAN AP/Client channel.   (Don't have it, have not seen it)  If they are different, I would assume one still needs to change the routers AP side channel to match the WAN, which means re-configuring the LAN client???  Maybe should move this discussion to the other thread, though some of it is still relevant.
https://forum.openwrt.org/viewtopic.php?id=59101

RangerZ, let me try with another example.  Let's say you have a hootoo that, the last time it was used, had been connected on Channel 1 using a hotel's SSID=HOTEL1.  Now you get to a new hotel which has SSID=HOTEL2 on Ch6.  Using the default firmware on the hootoo, when you power it up, it has erased the HOTEL1 from its memory and starts broadcasting its own SSID=HT02, let's say, on Channel 11 (it doesn't matter which channel, your Windows machine will be scanning all channels to find SSID's it recognizes).  The hootoo is making no attempt to connect its WWAN at this point.

So, you connect your computer to HT02 (on Channel 11), then, using the original firmware, do a scan for other SSIDs.  The hootoo does the scan, and reports back that there is a SSID of HOTEL2 (coincidentally, on Ch6).  You select this SSID to be your internet provider.

Now, the hootoo brings down its wifi connection, then reconfigures itself to have WWAN via HOTEL2 on Ch6, and also, configures a VSSID=HT02 in AP mode, also on Ch6.  After a short while, your computer reconnects to HT02 (now on Ch6), and the hootoo routes your traffic to its WWAN on SSID HOTEL2, also on Ch6.

I cannot be certain this is exactly how it is implemented, as I cannot review the code, but I would bet a fair amount that something like this is implemented in the original hootoo firmware.  Something very similar is done using the GL-iNet app if you are using a 6414 instead of the hootoo.

TL;DR=Your computer will find the HT02 SSID, regardless of what channel it is on.  You don't need to configure the channel, just have the hootoo do a wireless scan, and then you choose which SSID you want to use on the WWAN side.  The device (either hootoo or 6414) shuts down its wifi, magically reconfigures itself correctly, then brings the WWAN+WLAN up for your wifi enjoyment.

(Last edited by klaberte on 17 Sep 2015, 01:12)

OK, so you are saying that the initial LAN connection finds a NEW and different WAN channel, and re configures itself to match the the WAN it has just found, and then does a restart to make the change.  OK, I can buy that, though not sure that the LAN client has the ability to change the channel it has saved for the connection.  When I look at my laptop's config for the wireless connection it usually says a channel number, not auto.  But maybe it's just reporting the current channel.  In any event I think it's a good logical way to approach the issue.

I'll see what I can do.

RangerZ, did you ever play with the stock ROM on the HT02?  Use the HooToo app on your phone?

Not sure where the confusion is (or even if it exists), but here is something you can try.  Connect your laptop wireless to your home AP.  Then manually change the channel on your home AP uses to provide a wireless connection.  Disconnect your laptop's wireless and then reconnect (or if you prefer, reboot the laptop).  My guess is your laptop will automatically connect, without uttering a peep, to the old SSID on the new channel.

In the same way, on your hootoo, after you've picked the hotel's SSID and the hootoo turns off and on the wifi, your laptop will reconnect to the TM02 using the same old SSID, but possibly different channel (aligned with the channel used by your hotel).

Thanks for the suggestions, I have learned a bunch of new info which is gonna save me some time and help me refine my expectations of what can be done with these small routers.  For now I already have the Edimax USB2Eth dongle on the way.  The piggybacked routers sounds interesting, but also more complicated for power and keeping configs straight, but I may need to go that route if the throughput suffers too much.  The GL-inet products look cool and they may be innovative enough to make something down the road with dual radios, however unless the Atheros chipset / driver in their current offerings handles AP+STA better (that is, it works), I think I will keep poking at getting the TM02 working the way I want it to, for now. 

The discussion on how the stock TM02 may accomplish the AP+STA modes, without crashing both WWAN and WLAN, got me thinking of trying something similar (not the same as described, yet something that may have been workable), but it appears to have failed.  Here is what I tried for reference:

Started out with this:
WWAN = AP (no encryption)  SSID = TESTING2 (DHCP client)
WLAN = AP (WPA2 PSK)  SSID = Openwrt (static w/DHCP server)

Edit - forgot to mention that I had the following config for the radio in /etc/configs/wireless (copied by hand):
config wifi-device 'radio0'
      option type 'mac80211'
      option channel 'auto'
      option hwmode '11g'
      option path '10180000.wmac'
      option txpower '20'
      option country '00'
      option disabled '0'

This worked

Then I tried scanning for a network...found my GW Router's Guest SSID (TESTING) which is unencrypted and connected to that as the WWAN (associated with the wan interface) - which would have replaced the existing config for the WWAN AP mode SSID = "TESTING2" (or at least it appeared to do so in LuCi). 

When commited, the HT02's blue led was blinking furiously and then I was disconnected from WLAN "Openwrt", it appeared that neither "TESTING2" or "Openwrt" were visible anymore, even though the TM02 Blue led was lit)...waited several minutes with no change and then reset the TM02, and confirmed that I could see it's MAC connected to my GW Router on "TESTING", but I was no longer able to see "Openwrt" for the WLAN. 

I tried a few more resets with no change, confirmed that WWAN connects to my GW Router, but WLAN (AP / SSID = "Openwrt") does not come up now. 

I also tried turning off the GW Router SSID = "TESTING", and as expected that appeared to kill the WiFi entirely (blue led on TM02 went out).  Now I need to get back in using the wired Ethernet which may take a while (but used to this by now).

(Last edited by IdiotProof on 17 Sep 2015, 04:06)

Good, you are digging in, learning, and sharing.  That's what this forum is about

Why do you think the Gl-iNet Atheros chipset doesn't handle AP+STA?

Not sure what this means.  It appears that you have assigned the hootoo two instances of AP.  I don't know what WWAN = AP means.

In what sense?  Sure, you could connect to the hootoo on SSID=OpenWRT, but unless the hootoo is connected via ethernet to your GW, I doubt you had internet connectivity.

So you exchanged one of your AP instances with a client instance, discovered using a scan.  At this point, you have configured, but not committed, a Client instance using DHCP to get an IP from your gateway, and assigned it the WWAN side of your firewall.  At this point, your security scheme, and perhaps your channels, do not match, and will create problems once you commit (as we will now see)

I'm not surprised that this doesn't work, but I don't know if it is because of the mismatch in encryption, or different channels.  Try your experiment again, but this time set the OpenWRT AP to use no encryption before you commit your changes.  See if that works.

@klaberte, I am wrong and you are correct. 

I have tested the Windows Zero Config tool, the EDImax tool, my iPhone, and my ancient IBM Thinkpad Access Connections tool and all will correct for and connect seamlessly after a channel change on the HooToo WLAN.

So there are even more issues with the OpenWRT wireless connections process than thought.

I also now realize that the OpenWRT tool will allow one to hide an SSID, but not find a hidden SSID in the scan.

In fairness, I think we, the road warrior champions of small routers, should concede that most OpenWRT devices do not spend their lives packed in briefcases and suitcases, expected to change their gateway connections after one night of dependable service.

All the tools in the trunk Luci OpenWRT are there, they are just not streamlined for our use case.  This gives added credit to companies like GL-iNet that addressed this use case by writing a simple app/web-interface  to quickly configure (on a smartphone, no less) the router for travel use.  I'm sure it wouldn't take a seasoned script-author much time to regenerate this functionality into an open-source script, suitable on most OpenWRT devices, but there just hasn't been enough demand for someone to take the time.  Perhaps we can nag alzhao to do this for us:-) 

But then, RangerZ, you would owe it to them to buy one of their devices :-)

(Last edited by klaberte on 18 Sep 2015, 03:11)

I had thought (probably misread between the lines here) that the issue of the WWAN (STA) not finding it's AP and crashing the wireless was an OpenWRT issue, rather than a chipset driver issue.  Since then I found a reference to the problem being seen with the mac80211 driver below (so seems more of a driver issue?):

http://wiki.openwrt.org/doc/uci/wireless
"mac80211 STA mode supported on trunk. STA and AP at the same time is not yet supported(r22989)."

Also info here which says mac80211 treats STA and AP differently:
http://linuxwireless.org/en/developers/ … /mac80211/

I will need to research some more if the Gl-iNet with the Atheros chipset may work with AP+STA - if you are aware that it does work with AP+STA (on the same channel of course), please let me know.

Here I was trying to see if bringing up the WirelessWAN (which I was referring to WWAN) as an AP would allow the Wireless LAN side to come up (that is not crash both sides).  WWAN was not a configured interface name, just the shorthand I was using here.  This setup (AP+AP) did work and the Wireless LAN side did come up.  This was simply the initial (and useless) condition I wanted to test, so I could get into the router from the Wireless LAN before I tried to scan for a wireless network to associate with the wan interface.

You are correct the WAN was down, this was simply testing that the WAN side as AP did not crash the wireless and I could get into the Wireless LAN side (AP) when the Wireless WAN side was also set for (AP).

When I can get back into the router I will check to see if the Wireless WAN (STA) associated with the "wan" interface or not, which could have messed up the firewall rules (though after commiting, the SSID for OpenWRT did not show up so firewall issues would be secondary).  Channel was set for "auto" for what it's worth. 

This to me was the only surprising part of the test, since I had expected STA+AP to work when the wireless WAN (STA) did not have encryption set (which was the case - and it was connected).  However the LAN AP side did not come up in this case (I could not see the SSID on my laptop).  I have had AP+STA working - and able to pass traffic - by manually configuring (not scanning) as WAN (STA) / no encryption / DHCP client and LAN (AP) / WPA2 / DHCP server.

Thanks for the suggestion.  I will give this another shot with no encryption on either side (before scanning), when I get some time off work to get back in via the Ethernet and take another poke at it. 

Just so you don't get the wrong idea, I do understand that AP+STA does not work correctly with OpenWrt on the TM02 (it does work by using no encryption on the STA side however).  I now know that AP+AP works (though is useless to me) and I still would like to see if going from AP+AP to AP+STA by scanning may work in some way.  However, getting encryption working on both sides, seems to be the problem with AP+STA, so I plan to move on from here to use the USB2Wifi adapter when it arrives.