Official www.freshtomato.org - Website


It is only able to pull the search queries from unencrypted (HTTP) connections. Now that all the major search engines upgrade the connection to HTTPS, this feature no longer functions as it used to. If you can get a device/browser to submit a search query unencrypted, it should appear in that list.

This switch to "HTTPS everywhere" also affected the Recently Visited Web Sites list until a couple years back when someone upgraded the code to work with HTTPS connections (which is only possible because the domain name is part of the initial, unencrypted handshake—necessary because different websites will have different security certificates, but can be hosted on the same server/IP address, which means the server has to know which site to direct the handshake process to in order to retrieve the correct cert for the applicable domain).

Used this and what rs232 wrote below and added a little editing to to make a clear explanation on the Web Monitor page. Thanks.
 

rs:​


You wrote:

Source Bound Redirection​

If the source IP and/or FQDN is well-known you can create multiple port mapping references on the same port:protocol as long as the source is defined differently. The following settings would work fine:


I've heard of well-known ports, but I've never heard of a well-known FQDN. I Googled and found nothing. Can you please explain what you meant here?

Did you mean that the hostname of the FQDN would indicate a common socket? For example, that www.domain.com would use a web protocol. But it could use two usually, http or https.
 
Last edited:
No a socket is a unique combination of IP and port.
FQDN in this context is linked to the source e.g. the host/device initiating the connection.
If this matched the FT port mapping rule (the specific rule) is applied, if not the generic (without source specified) is applied. Does it make sense?
In my example I used port 80,443 but it's irrelevant just think of 80 to keep it simple.
 
I know what a socket is. But I'm still lost. There's no such thing as a well-known source IP either. There's only well-known ports.

So, if I understand this correctly, all you're really saying is that:

1. Port Forwarding is capable of some simple multiplexing and;
2. You can specify an IP or FQDN, which will allow traffic from a specific place to be forwarded, separately from if you only specify an in and out port.

It would appear to have nothing to do with "well-known" anything.

And now that I look more closely, "source bound" is a direct contradiction. Nothing can be bound towards the source, it can only be bound towards the destination, away from the source. Assuming I was ignorant, I Googled and found zero hits for "Source bound" anything. Can you maybe use another, less confusing term? Is there an industry standard term for what you wrote?
 
Last edited:
I know what a socket is. But I'm still lost. There's no such thing as a well-known source IP either. There's only well-known ports.
Are you lost because you don't understand what this achieves or because the English doesn't sound right?

So, if I understand this correctly, all you're really saying is that:

1. Port Forwarding is capable of some simple multiplexing and;
2. You can specify an IP or FQDN, which will allow traffic from a specific place to be forwarded, separately from if you only specify an in and out port.
Specifying a source IP has always been there and it used to be a sort of security feature, e.g. say I have a traveling laptop with a DDNS client installed I would set up the port forwarding towards certain internal IP to be made available only for my device.
This particular advanced scenario documents how for a defined port/s the actual mapping can react differently based on where the source comes from. Nothing more nothing less.

It would appear to have nothing to do with "well-known" anything.
As far as I read (not that I have ever performed such a google search before in my entire life) "well known" is proper English.
You might argue a domain name is public info hence well known a.k.a. public knowledge. When it is appropriate to use known Vs well known I'll leave it to you. As you know I am not a native English speaker and especially I have nearly 0 interest/drive in semantic; hence I find this conversation particularly difficult and energy consuming. I'll help you clarifying the technical stuff but don't ask me to justify why I used one English word instead of another, it obviously made sense to me, if it doesn't just change it.

Thanks

\\edit:
1699708515361.png
 
Last edited:
@M_ars @Hogwild

Since I have never used myself media/ethernet bridge before, as a feedback I think in the above article we assume the the user already knows what media bridge is. To cover the case when this is not true, is it worthy adding an introduction to cover specifically:
- how and when to use this (as in what problems does it solve)
- how it will affect the IP addressing on LAN/WAN (e.g. DHCP will be coming from the main AP)
- implications on NTP/DNS intercept (I believe these currently work on iptables and I'm unsure if we have an ebtables equivalent yet, perhaps we should?)
- LAN <-> site-to-site VPN routing (again probably some ebtables tweaking is needed to retain site-to-site VPN interoperability I suppose?)

Just to improve the wiki and perhaps add some ideas on what else media bridge could perform.

Thanks
 
Offtopic - we need to add AIO_lite target for ARM branch at the FT wiki

Is this definitely ARM only?
Regardless Where does this fit (e.g. what flash size) greater than 8MB?
Or perhaps the right way to document this is that it needs to fit within 32MB?

Thanks
 
@M_ars see this version of the feature_matrix table:
1699722539417.png
It's a sort of heavy redesign, here the list of changes:
- split all the build headers into two so eg. MiniIPV6 is now "Mini IPv6" this makes it auto carriage return resulting in slimmer columns when needed. This should make the table better visible on "narrow" screen resolutions.
- Renamed some options to be shorter
- Adblock had the emoji removed to have only the version documented (since it's present in all the builds)
- Introduced footnotes so that some options can benefit from both tooltip onmousehover and automatic Notes section at the end of the page, notice the numbering next to the options (in red).
- rearranged the ARM part to capture flash size implication and add AIO-lite
- rearranged the Flash size part across the table to make it friendlier to smaller resolutions

Question: is the last column ARM-AIO >=32 correct?
 
Last edited:
It looks like the incorrect MD5SUM for the “R-series initial file” for R7000 may be listed at https://wiki.freshtomato.org/doku.php/firmware_basics_procedures#netgear_r-series

Listed on the Wiki (which matches the MD5SUM for AIO build file listed after):
ec63c869fe14f5b46cbb13813c1699bf

The MD5SUM I continue to get:
e3ef483d088215e9abe4888e0dd36d37

I've gotten the same MD5SUM a few times and wanted to report the mismatch in case this was a typo.
 
@M_ars see this version of the feature_matrix table:
View attachment 13011
It's a sort of heavy redesign, here the list of changes:
- split all the build headers into two so eg. MiniIPV6 is now "Mini IPv6" this makes it auto carriage return resulting in slimmer columns when needed. This should make the table better visible on "narrow" screen resolutions.
- Renamed some options to be shorter
- Adblock had the emoji removed to have only the version documented (since it's present in all the builds)
- Introduced footnotes so that some options can benefit from both tooltip onmousehover and automatic Notes section at the end of the page, notice the numbering next to the options (in red).
- rearranged the ARM part to capture flash size implication and add AIO-lite
- rearranged the Flash size part across the table to make it friendlier to smaller resolutions

Question: is the last column ARM-AIO >=32 correct?
i will check it tomorrow (flash size limit for example), but i like the change 👍
 
It looks like the incorrect MD5SUM for the “R-series initial file” for R7000 may be listed at https://wiki.freshtomato.org/doku.php/firmware_basics_procedures#netgear_r-series

Listed on the Wiki (which matches the MD5SUM for AIO build file listed after):
ec63c869fe14f5b46cbb13813c1699bf

The MD5SUM I continue to get:
e3ef483d088215e9abe4888e0dd36d37

I've gotten the same MD5SUM a few times and wanted to report the mismatch in case this was a typo.

I just tried it to verify and got the same MD5SUM, ending in dd36d37, so it seems you're probably correct.
 

Back
Top