This really looks like it should have a semi-colon. Somehow the PHP interpreter is not being fussy about it in this context, I guess being followed by the "endif;" keyword the interpreter guesses the previous statement must be done.
1) consider where the LAN IP is in the subnet range and then put the
DHCP pool in the biggest remaining segment, either above or below.
2) Check the size of the available segment. If it is reasonably big then
leave some space at either end of the segment, like the old code was
doing. Otherwise give all the space to the pool.
3) Do not allow subnet mask 32 - I can't think of a use case for LAN to
have a /32 subnet mask, it kind of breaks the whole concept of LAN.
4) Provide more detailed separate messages if the user tries to use the
network address or broadcast address as the LAN IP.
Redmine #4712
It seems good enough to make the regex strings here be "reasonable". The full checks are done after pressing Next and the correct routines are called that do an exhaustive check. There seems not much point in trying to re-engineer all that here also.
Odd things like "-hostname" and "hostname-" would be allowed through here but are caught by the full validation check.
"." and "|" were being allowed in this regex - no idea why!
As per comment in https://redmine.pfsense.org/issues/3633 sometimes the
server end only requires a password, no username. Usually 1 long string
that serves as the hard-to-guess authentication. OpenVPN expects
something to be on the first line of the ".up" file - traditionally
called the username. It also insists on the second line being present,
but is happy with it being empty - this is the authentication
information traditionally called "password".
Let the user put the single piece of authentication information in
either the Username or Password field on the web GUI - whichever they
feel comfortable calling it. In the ".up" file it has to always be the
first line to keep OpenVPN happy.
a) When we are doing combined fields and usecolspan2 is in effect, then usecolspan2 is also a signal that we want to spread the combined fields horizontally in a single row. In that case we want the combined fields to all be in a single "tr" tag enclosing them all. That was already working in that way.
b) But if usecolspan2 is NOT in effect, then we want the combined fields to still run "together" but vertically under each other. In this case we want each field to be in its own "tr" tag.
This change makes (b) happen.
If combinedfields is not set, then each of the "if" tests here still follows the same path it did previously, so there should be no effect on the HTML output for any ordinary package fields.
Actually the "tr" tag needs to be a single tag-pair that encloses all of the set of fields with combinedfields specified - combinedfields=begin is where the "tr" tag starts and combinedfields=end is where the "tr" tag ends, enclosing a whole set of combined fields.
That allows usecolspan2 to work.
In the previous change I had made it enclose every field in its own "tr" tag-pair That caused usecolspan2 to be ineffective at spreading the combined fields across the display.
Also colspan needs to be initialised each time around the loop - it was getting applied to all fields further down the page after the first one it was used in.
This is the version for 2.2.*
Even with this fix, the code does not make sense. The first test is:
if ($startingat > -1)
if it gets into the else, then $startingat must be negative. But the test in the "else" tests for >1 ???
Someone who knows what it really is supposed to do could fix it!
These "if data" tests look like they should apply to all 4 lines below them.
After sorting out this real-looking issue, I can mess with the rest of the formatting...
1) Variable $i is was set, incremented and not used.
2) "if preg_match" at line 94 had no curlies after it, so it was only applying to the first line after it ($rdr_proto = ...) It really looks like "if preg_match"should apply to the whole code chunk - settings the various "rdr*" vars and then spitting out the "tr" with the various matches values in the row.
Somebody with some various UPnP enabled and running should test this to see if the status page still works with this change.
I think it only makes a difference if $rdr_entries has some lines in it that do not match the regex - in that case the old code might have displayed some rubbish or (almost?) duplicated rows.
This change makes it possible to have host with identical hostnames in different (sub)domains. For example myhost.sales.acme.com and myhost.support.acme.com will now be possible.
This should be the end of a "tr" here.
Browsers seem to be forgiving of this stuff - I don't see any difference in rendering in Firefox before or after this change.
This file seems to have an unmatched "td" ending. Adding the line here matches the "td" at line 320 and this embraces the little table that has the 4 icons in it in a square that comes at the right hand end of each port-forward entry in the main table.
I can't see any difference in the rendering of the page, at least on Firefox, with and without this fix.
The tabbing of this file is woeful. I am fixing that up with a code-style review. But thought I should do a separate pull request for this kind-of-functional fix.
