I am a beginner looking into a router with OpenWrt support to do some experiments. I am puzzled with the relationships among the different versions of software loaded in the hardware product, the file downloadable from the vendor and that available from OpenWrt.
When I spoke with vendor's chat operators, they told me that their products are loaded with their proprietary software. But, the firmware (BIOS?) in the product is ready to accept OpenWrt software. It seemed to make sense.
However, when I get to their software download area, it seems to say what is the hardware is already a copy or close-derivative from OpenWrt. For example, below is a description just above a list of files available for download to one of TP-Link's routers.
" GPL Code Center
Please note: The products of TP-LINK partly contain software code developed by third parties, including software code subject to the GNU General Public Licence (“GPL“), Version 1/Version 2/Version 3 or GNU Lesser General Public License("LGPL"). You may use the respective software condition to following the GPL licence terms."
Of course, The word "partly" is tricky. What percentage does this refer to? To what degree of TP-Link's modifications that still deems the end software public? Could anyone guide me to a definition? If what the vendor puts into their hardware is still a public software, then the download from the vendor' website would be a public version for backing up the product. Why do we have another parallel version offered from OpenWrt?
If I recall it correctly, I believe that this public router software subject was started years ago by LinkSys. They used to have similar notice on their website. Now, they do not. What I see is a long list of GPL codes to support most of their routers, versus a much shorter list of codes that appear to be their in-house software. So, which version is in LynkSys' routers, their proprietary or OpenWrt version? Could anyone please clarify these?
" Why don't you ask the manufacturers these questions? ":
As I reported in my posting, I have already talked with manufacturer's staffs. Both TP-Link and LinkSys told me that what is in their product is their own (proprietary) software. But, looking at the way that their backup software downloads are listed on their support pages, most of them appear to be GPL version anyway. This is why, before I go back to them, I would like to hear from any colleague on this forum who may be able to clear this apparent contradiction from OpenWrt's perspective.
OpenWrt started when Linksys was caught using GPL software (BusyBox, if my memory serves right), and was forced to release the affected sources for their (up to then) closed firmware. That oppen the gates to install homebuilt firmware on the device, and OpenWrt was born.
Some time later, some manufacturers decided to sell devices with modified versions of OpenWrt, and are required by the GPL to release such modifications. However, what each manufacturer installs in the device they sell is entirely up to them.
Thanks for the assurance of support from many members.
"TOH":
I have studied this list. It is overwhelmingly long. But, I have narrowed it down to TP-Link Archer C20 AC750 for it being reasonably priced ($34.99) at a local mass merchandiser (B&H in NYC) and without cautionary limitations. Do you have recommendation for equally capable yet lower cost ones? My goal is to recommend as many friends as possible to replicate my scheme once I can verify it. Thus, the hardware choice should be as simple to handle and low cost as possible. So that hopefully dummies can enjoy my approach.
If you're flashing your own firmware anyway, why do the restrictions listed in the TOH matter to you?
FYI, if you're referring to the scheme noted in other threads, your friends will have to be directly connected to the same broadcast domain...on a closed system...not connected to the Internet - for your testing to work.
Actually I would suggest you go in the opposite direction and purchase an enthusiast router ( many are mentioned on this forum) since you will be testing, having more ram and flash could be beneficial in adding test tools and performance and monitoring tools. Once you have stable software configuration you can focus on optimization and using more economical hardware.
Yes, if one works, I will try to verify on others to make it more accessible for more people. However, I would like to start from lowest cost product for a couple reasons:
A. To prove that "there exists a solution" like proving a mathematical theory, to set a baseline for moving the subject matter forward.
B. In addition, one of my life-long rules for this kind of experiments is to start from the lowest cost hardware that is possible / capable. Once it is proven, I will have much easier time dealing with other higher priced product manufacturers, because I can give them the working example to challenge them.
" doing this in a lab isolated from the interne ... ":
Well, even I tried very hard, like it or not, your curiosity question leads us right back to the point that I had to explain "why" and "how" to provide some credibility for getting your further help. Otherwise, you will regard me as crazy. Let's be professional to stay on the track so that this thread does not get closed by SysAdmin again. Thanks.
Please have a look at the diagram on page 8 of the following whitepaper:
The router that I am trying to buy is to be used as the SPR in the middle of the setup (red legends). Since it is positioned as a CPE behind the Public / Private Demarcation line (if we do not move the current blue line.), what I will be doing with this new inline router, is beyond my ISP's concern. Correct?
"your friends will have to be directly connected to the same broadcast domain...on a closed system...not connected to the Internet - for your testing to work. ":
Allow me to postpone responding to this aspect, until after my current step is verified. Otherwise, we will be trapped into the distractions in the previous threads again, causing the SysAdmin to close those threads.
If I can verify the 240/4 routability by OpenWrt in the S/W of a PC first, I will have much more confidence to deal with the flushing a hardware router for operational purpose.
I do have a couple older Notebooks that have been hanging around because they are still functioning, but overburdened by continuous OS and application S/W updates.
A. The first one is an old trusty HP with WinXP, slow but reliable.
B. The second is an HP with WinVista, works Ok but somewhat unpredictable.
C. The third is an Asus withWin7, seemed to be marginal right from it was new..
What kind of hardware configuration should I look in them to qualify for supporting this approach?
Not necessarily. It depends on what portion of the technology you're attempting to implement in your experiment. Also, if you are testing the portion of the technology where packets traverse the Internet to other enabled devices, this needs to be done in a closed, disconnected environment, first.
Also, per the image on page 8, that router has a Public IP addresses, and, therefore IS NOT beyond your ISP's concern.
This was suggested to you multiple times!!!
You should know this, you're the one who has connect network interfaces!?!?
This is done in software anyway. So again, why are you greatly concerned about hardware specifications!?!?
I just realized that the document you posted here is not compatible with the draft RFC you showed in a previous thread. They appear to describe two different technologies.
This technology requires all current routers on the Internet to be replaced with an infrastructure running your software.
This document never discusses intra-SPR transport using the IP Option field in the header (it only references the original figure filed by DARPA in 1981).
It seems like you're only re-coding the OS of the router to use a restricted IP space...I'm not sure what discovery of new technology that will provide. I hope the best. This is known to work, you even referenced an expired RFC draft that says this works on Mac OS.
This proposal seems the same as Carrier-Grade NAT, which is already widely practiced (though not very well liked). For example Verizon does not assign public IP's to every customer's LTE phone, they are NATted.
Why would a different block of private IPs be required? The 240/4 has only 16 times as many addresses as 10/8. Verizon uses the 10/8 block. They do have more than 16 million customers, but they can reuse the whole block in different regions of the country.
Also note that it is not possible to NAT millions of customers (or even more than a few thousand) out over one IP address. NAT works by allocating one of the 65535 ports to each connection from each customer. Unless maybe it is a very low use scenario like electric meters that only open one connection for a total of a few minutes per day.
You seem to get off teh track again, such as mentioning Mac OS. With due respect, please contact me via eMail directly to discuss in detail while avoid burdening colleagues on this forum.
No, if you need to re-code, and MacOS already uses it, why wouldn't you realize that's on track, and that you can use the Darwin code for those needs???
You flagged a couple very valid points. Since our proposal is so unorthodox, it is kind of difficult to see through it. Running the risk of getting closed by SysAdmin again, allow me to briefly address them. I will entertain detail exchanges via direct eMail which you can find at the end of the EzIP Draft.
"This proposal seems the same as Carrier-Grade NAT, ... Verizon uses the 10/8 block ":
Yes, structure-wise, they are very much the same. The difference is that CG-NAT is deployed in the public portion of the Internet, thus is restricted by certain rules in that environment. 10/8 is designated as a private netbolck. So, Verizon, as an ISP, has to be extremely careful about using it in their part of the network which is public. EzIP is deployed on the end of each IPv4 address which is in the private domain from the Internet's perspective. On the other hand, EzIP is in front of a private premises, so it looks like in the public domain from end-user point of view. We call this newly identified space semi-public, allowing the free use of the 240/4 netblock, not only NAT but also including routing with plain IP header within each IPv4 address. This results in multiplying the assignable public IPv4 pool by 256M fold.
"Also note that it is not possible to NAT millions of customers (or even more than a few thousand) out over one IP address. NAT works by allocating one of the 65535 ports ... electric meters .. ":
You are among only a few people who saw this angle! Your question is exactly correct. The purpose of the EzIP scheme is not trying to NAT the whole block of 256M addresses to the single IPv4 address for Internet access, but through the concentration and local services within the region to reduce the "final" traffic on that single access channel to something manageable. This is where caching gateway technology comes in as described in the EzIP Draft. For a region as big as Tokyo Metro that each block of 240/4 can serve, there should be no double about whether web-servers like Google, Amazon, etc. will set up their own caching gateway there to reduce the traffic to their main data banks. Low traffic like electric meter reading, etc. will be handled by neighborhood utility offices via packets utilizing basic IP header with 240/4 address. This is described in depth under subsection 3. C.
The simple answer is that it will be managed the same way as how telephone numbers used to be administrated by telephone companies. This reusable address block is out of the hands of IETF, etc., because it is in a newly identified cyberspace. For detailed discussions, please contact me via eMail.
