HTTP content comparison for captive portals
jonesmz opened this issue · comments
I have a situation where my OpenWRT device might be deployed behind a captive portal style firewall, which will intercept TCP traffic and redirect, but won't intercept ICMP.
I'd like to have the ONLINE status of an interface be the logical AND of all configured protocols.
Is this practical?
Yes would be possible but unlikely i implement it in the next couple of months...
I will try my hand at implementing support for this.
Can you give me some suggestions on how an "acceptable to merge" pull request would look from your perspective?
Hmm, thinking about it I don't really understand the requirement. If the captive portal doesn't block ICMP it would go thru and you can check if you are online "theoretically" (independent if the captive portal blocks TCP or not). If the portal always redirects TCP traffic, what do you gain by testing for TCP as well (it will always be positive)? Maybe I misunderstand but I'd like to make sure the feature is useful if i spend time implementing it
I'm no longer involved in the project that this feature request was opened on behalf of, and no longer intend to work on this feature.
But to clarify my meaning here, my objective was to take the code that was added for this feature request, and enhance it to allow for checking a full http connection with content comparison. E.g. check the public Google or Mozilla captive portal check pages against a static string in the config file.
The reason for wanting this to be done at the level of the pingcheck program is to allow for the event that gets generated when the complex-ping fails to drive higher level program behaviour. E.g. I wanted one centrally located place to say "This connection is able to support general purpose traffic".
Yes that would make sense. Changed the title accordingly.