Closed teward closed 9 years ago
Update: It looks like this is a case of mangling of IPs. The problem with v6 is that it's evil. And the problem with v6-formatted v4 is, it doesn't like working as it should. This might need adaptive changes.
Here's the log data from stdout
that shows this:
WARNING 2015-04-04T18:41:52 '::ffff:192.30.252.41' tried to act as a web hook for Github, but is not GitHub. INFO 2015-04-04T18:41:52 HTTP request: ::ffff:192.30.252.41 - "POST /github HTTP/1.1" 403 -
So this is actually a case again of bad IP matching.
Okay, so I'm partly wrong.
There are two problems. Firstly, this is the default startup with supybot-wizard
now for http server hosts:
### # Space-separated list of IPv4 hosts the HTTP server will bind. # # Default value: ### supybot.servers.http.hosts4: ### # Space-separated list of IPv6 hosts the HTTP server will bind. # # Default value: ::0 ### supybot.servers.http.hosts6: ::0
This causes a problem if v4 is not on - it will incorrectly do the v6 form of the v4 address, as seen in my last comment.
When you bind right to v4, it has no issue. There needs to be additional handling for this v6 problem.
Duplicate of https://github.com/ProgVal/Supybot-plugins/issues/270
Potential solution fixing also multiple other GitHub issues https://github.com/ProgVal/Supybot-plugins/issues/230
Only solution that I see to web server being stupid without having any coding skills https://github.com/ProgVal/Limnoria/pull/1074
@ProgVal You might want to close this, it's a duplicate.
This sounds like https://github.com/ProgVal/Supybot-plugins/issues/264 again, but it's probably a different bug now. What's odd is that the server is in the ranges defined in the code, but apparently not being recognized.
REQUEST
Headers:
Payload:
RESPONSE Headers
Body
Firewall Log Entry: (Confirms the request came in and was routed to where it needs to be)
Action: pass; DateTime: Apr 4 17:36:14; Interface: WAN; Src: 192.30.252.34:37865; Dst: 10.255.50.10:8888; Prot: TCP:Syn