Skip to content

fix: Handling ip addresses in format of ::ffff:192.168.0.1 - #4

Open
John222 wants to merge 3 commits into
O-X-L:latestfrom
John222:latest
Open

John222 wants to merge 3 commits into
O-X-L:latestfrom
John222:latest

Conversation

@John222

@John222 John222 commented Sep 20, 2025

Copy link
Copy Markdown

In case the haproxy is running in Ipv4 and IPv6 mode, the haproxy maps Ipv4 addresses in the IPv6 format. This fix converts the IPv4 mapped address in IPv6 format back to a regular IPv4 address like 192.168.0.1

In case the haproxy is running in Ipv4 and IPv6 mode, the haproxy maps Ipv4 addresses in the IPv6 format. This fix converts the IPv4 mapped address in IPv6 format back to a regular IPv4 address like 192.168.0.1
@superstes
superstes self-requested a review September 21, 2025 07:27
@superstes

superstes commented Sep 21, 2025

Copy link
Copy Markdown
Member

@John222 Yeah - makes total sense.
Do you mind trying a non-regex alternative? It might perform marginally better

local V4_MAPPED_PREFIX = "::ffff:"
local PREFIX_LEN = 7

local function normalize_ip(ip)
    if ip:sub(1, PREFIX_LEN) == V4_MAPPED_PREFIX then
        return ip:sub(PREFIX_LEN + 1)
    end
    return ip
end

In my tests it worked

@superstes superstes added the enhancement New feature or request label Sep 21, 2025
@John222

John222 commented Sep 22, 2025

Copy link
Copy Markdown
Author

Hi @superstes i tried your suggestion. It worked.

Fixing the issue that the go backend is returning the string with quotes which breaks in haproxy when comparing the string. As haproxy escapes quotes to '#22' ascii character.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants