Fork 380.57 HGG-FINAL

[sfx2000]

But the point really is that HGG fork empowers users to break RF regulations almost in every single developed country and emerging markets on Earth. In addition to that is the GPL violation which many open source believers cannot tolerate. Together then advocating HGG fork makes your appeal to "FCC crippled my router" not any more morally right.

HGgomes firmware is not impacted by FCC's decisions, nor anyone else - when it comes to a specific AP running his firmware, and it's running out of the regulatory domain's specifications - it's the Operator of that radio that is most at risk...

Which means - if you're running his firmware, and operating your Router/AP in non-legal channels, or exceeding region specific RF tx limits, it's on you, not him...

I'm not defending HGGomes here - but folks do need to take responsibility for their own actions as well..

 

[sfx2000]

Together then advocating HGG fork makes your appeal to "FCC crippled my router" not any more morally right.

FWIW - FCC (or any other regulatory agency) isn't out to cripple any single user's device - to be honest, they don't care about one single person - but consider that they are trying very hard to manage a very useful resource for 10's, 100's of million devices, then it becomes a big deal - esp when trying to keep those resources available as secondary users on shared spectrum with licensed users (that's why in the US, we have the TPC/DFS channels, FCC opened them, but there are other users, licensed users already there..)

So the whole "FCC (blah blah blah) crippled my router" argument has little weight...

Mainly because the FCC, or any other agency, doesn't give a flying flip about your feelings other that to ensure that your device works correctly and doesn't interfere with other uses... but if it does interfere, they're going to ask you to make changes to make the interference stop, and they have the power to make it happen...

 

[got_milk]

HGgomes firmware is not impacted by FCC's decisions, nor anyone else - when it comes to a specific AP running his firmware, and it's running out of the regulatory domain's specifications - it's the Operator of that radio that is most at risk...

Which means - if you're running his firmware, and operating your Router/AP in non-legal channels, or exceeding region specific RF tx limits, it's on you, not him...

I'm not defending HGGomes here - but folks do need to take responsibility for their own actions as well..

Well said. I'm also interested to see what happens when radios in people's routers begin failing as they were running out of spec...the RT-AC87U has plenty of cooling issues already with stock firmware.

 

[sfx2000]

Well said. I'm also interested to see what happens when radios in people's routers begin failing as they were running out of spec...the RT-AC87U has plenty of cooling issues already with stock firmware.

So... providing an out... HGG's firmware might help out some, and getting this into the RMerlin brach might be a good thing - that's what GPL is all about - open collaboration...

1) Solve the GPL issue if HGgomes wants to go in that direction - check in the commits to the maintainer that he pulled from and stop distribution

2) If you're running HGgomes firmware - one is doing at owns risk, simply put - respect the regulatory domain, and your fine - channels and Tx power - my recommendation would be to revert to Factory firmware, or better yet, check out rMerlin's branch.

 

[sfx2000]

RT-AC87U has plenty of cooling issues already with stock firmware

Well, the 87U seems to be a troubled child for some... challenging for many...

 

[got_milk]

So... providing an out... HGG's firmware might help out some, and getting this into the RMerlin brach might be a good thing - that's what GPL is all about - open collaboration...

1) Solve the GPL issue if HGgomes wants to go in that direction - check in the commits to the maintainer that he pulled from and stop distribution

2) If you're running HGgomes firmware - one is doing at owns risk, simply put - respect the regulatory domain, and your fine - channels and Tx power - my recommendation would be to revert to Factory firmware, or better yet, check out rMerlin's branch.

I still don't believe it's a matter of if - he is bound by the license to release the source, and I have once again asked in line with the license agreement for him to provide the source which he cannot refuse.

I do agree with the rest of your post however. Increased TX power comes at the cost of performance (throughput), and potential disruption to other wireless networks and devices in that spectrum. There are better ways to increase wireless range if needed - an AP bridge connected by Ethernet (or powerline if running a cable isn't suitable), or a wireless repeater. Both options will increase range while remaining regulation friendly and with probably better performance.

 

[got_milk]

Well, the 87U seems to be a troubled child for some... challenging for many...

I (regretfully) bought two of them. I'm learning to live with my mistakes.

 

[sfx2000]

I still don't believe it's a matter of if - he is bound by the license to release the source, and I have once again asked in line with the license agreement for him to provide the source which he cannot refuse.

I appreciate your concerns - and trying very hard to defuse this - if HGG sends the changes, and if he does this via GIT, all will see it, then it's not really a problem... you have a valid point with GPL in demanding, but at the same time, the harder one pushes someone into a corner...

Ultimately, he doesn't have to release everything, just the diffs based on the referenced branch, then anyone with technical ability can do the merge - but in the spirit of openness, it would be best to check the changes in...

HGG is a good guy with good intents... give him a chance to make good...

 

[got_milk]

I appreciate your concerns - and trying very hard to defuse this - if HGG sends the changes, and if he does this via GIT, all will see it, then it's not really a problem... you have a valid point with GPL in demanding, but at the same time, the harder one pushes someone into a corner...

Ultimately, he doesn't have to release everything, just the diffs based on the referenced branch, then anyone with technical ability can do the merge - but in the spirit of openness, it would be best to check the changes in...

HGG is a good guy with good intents... give him a chance to make good...

As I mentioned in an earlier post, it doesn't matter to me how the source is released - I would happily accept patches that could be applied on top of Merlin's source - but on the condition that the patches, when applied to Merlin's fork can be successfully built into firmware binaries (otherwise the source remains incomplete if he can build it but we could not).

My ideal preference would be to have the entire source archive uploaded as one buildable artifact - similar to how Merlin's fork is the Asus code + his modifications on top. I assume by his capability to merge to newer Asuswrt-Merlin releases he is using version control to do so (if not, it raises serious concerns about the development process and quality of the merges). Therefore it would be a simple matter to create a GitHub repository, point the local repository to GitHub, and push the firmware up.

Regardless of option chosen, whether the source is uploaded via git or .patch files in a .tar.gz archive, doesn't matter. The important part is that his contributions are made public in accordance with the license he agreed to.

The reality is this is an issue that's been dragged out over months, and hggomes has had many opportunities to make good by releasing his code, and he has either remained silent or refused to do so. I would be happy to give him the benefit of the doubt but as myself and others on this forum have raised previously, there is an 8MB difference in binary size between his fork and Merlin's firmwares, which is a very large discrepancy - not one I would expect with a few regulatory unlocks and some package updates. When questioned where the difference comes from, he does not answer. I believe that warrants skepticism and the only way for this issue to be truly resolved is for hggomes to come clean and release the source code, so users can trust what's really in the firmware images. As of right now, there's no clear way of telling.

 

[kvic]

HGgomes firmware is not impacted by FCC's decisions, nor anyone else - when it comes to a specific AP running his firmware, and it's running out of the regulatory domain's specifications - it's the Operator of that radio that is most at risk...

Which means - if you're running his firmware, and operating your Router/AP in non-legal channels, or exceeding region specific RF tx limits, it's on you, not him...

I'm not defending HGGomes here - but folks do need to take responsibility for their own actions as well..

This argument sounds very..very familiar but in a different setting. Gun sellers aren't bad nor good guys. It's the buyers who kill innocent people..

I guess laws in USA made with similar philosophy behind it

EDIT:

I'm not in complete disagreement with the argument. Just saying..

 

[got_milk]

This argument sounds very..very familiar but in a different setting. Gun sellers aren't bad nor good guys. It's the buyers who kill innocent people..

I guess laws in USA made with similar philosophy behind it

It's a valid argument. If your neighbour's Wi-Fi degrades due to your router exceeding it's maximum regulated TX power, you could not solely blame the firmware for that - it was your decision to download it, your decision to flash it to your router, your decision to push the TX power past the stock firmware's 100% value.

At the same time, the firmware author does share in some of that responsibility - much like the weapon dealer should perform background checks on buyers. But, if someone buys a gun and shoots someone with it, would your finger immediately point to the dealer for selling him the weapon in the first place? Of course not.

 

[sfx2000]

it was your decision to download it, your decision to flash it to your router, your decision to push the TX power past the stock firmware's 100% value.

At the same time, the firmware author does share in some of that responsibility

Slippery slope that argument is...

Don't like it - don't run it... simply put

HGG didn't force you to download, install, and run the firmware...

 

[got_milk]

Slippery slope that argument is...

Don't like it - don't run it... simply put

HGG didn't force you to download, install, and run the firmware...

That's fair enough. Still, his firmware does intentionally bypass regulation enforcement logic...I think there is a share of the blame there for providing it in the first place. But I suspect we'll disagree on that, so I'll settle for agreeing to disagree on that point.

 

[kvic]

Slippery slope that argument is...

Don't like it - don't run it... simply put

HGG didn't force you to download, install, and run the firmware...

If there is a clear disclaimer and users have to click to agree before download, then I would agree with you.

One observation I have on this forum is that users are mostly less techie. Hence, people who knowing a bit more perhaps shall take the responsibility to inform the rest.

Clearly warning messages aren't conveyed enough when people advocate this fork to the "innocent" users.

 

[The Asgard]

Well, the 87U seems to be a troubled child for some... challenging for many...

And zero issues for people like myself. Solid, just like my Nighthawk.

 

[Nullity]

Slippery slope that argument is...

OK... Yoda.

 

[Matthew Patrick]

What regulatory domain are you presently in?

If you're in the US, you get US channels - if you're in JP, you get Japanese channels, and so forth...

Macs look not just at your AP, but adjacent networks, and picks the most restrictive set - I'm not defending that, just reporting that...

Ok. So.lets say im on US. But. There are few weak neighbor wifi that have regulation to China. And one to US. so. When my mac just connected to my wifi. It didnt detect my wifi regulation. So it use universal channel. But now when the mac is searching wifi on background. It found a weak wifi with regulation stating its china. So my mac just change the regulation and froze the whole wifi. Cant even ping to router. And ps: im using channel 1 2.4ghz. So its available everywhere thx

I don't get it what is the issue with mac and regulations. Maybe somebody can help if you can provide more info about the problem.
Are you saying that mac is looking if the router has the regulations enabled?
Maybe you didn't used the right channel as per country regulations

 

[Matthew Patrick]

The router life is not impacted by this. Play with the settings until you will find what is the best for you. There is a triangle between range, speed(bandwidth and stability. you can't have all on maxim. In my case first is stability, then a range to cover my apartment balanced with speed. Default setting made by HGG seems to fit my needs. I activated only some filters on firewall, a printer, some dhcp custom settings and AiProtection/Network Protection

So. If i set like 1Watt. Then the speed gonna decreased so much? And btw. On ac3200 we cant like use low channel on high channel band right? Cuz its have 2 5ghz band for low and high channels

 

[steelskinz]

Any news about the RT N16 release ?

 

[MarkyPancake]

Each country's Wi-Fi regulation is different and changing rather rapidly. Asus's implementation is outdated and some even violate current regulation. (at least in my country's case, available 5Ghz channels have never been implemented correctly. I can avoid those banned channels, but cannot use some legally available channels and there are over 30 Wi-Fi routers around, it's such a pain)

Why not let the user decide which channel and output power they should use?

If merlin's firmware, bless him for his work, let those options open to the user, would there be a demand for HGG's?

Merlin actually does leave those open, you just need to be knowledgeable enough (hgg) to know how to do it. Asus/Merlin/John's code, aside from the Asus/Broadcom binaries, are available for anyone to play with & modify.

My N66U has always lacked some of the 5 GHz channels that are available in the UK, whereas my AC68U has those channels available and that's with both routers running the same firmware version and without any modifications by myself. Both are UK models. The main difference I've noticed is the bootloader version; the AC68U has a newer CFE than the N66U.