Conversation
Both source and destination were already passed through the resolver, but private LAN addresses have no public PTR record, so the LAN tab showed only raw IPs and WAN sources stayed numeric. - Resolver gains a static_names map (IP -> name), checked before PTR, like /etc/hosts; seeds the cache so local hosts display a name - Demo seeds friendly names for its synthetic LAN hosts and router so both endpoints resolve on both tabs - App passes the demo static names when building the resolver (both at startup and on the runtime 'r' toggle) - Bump version to 0.2.1; regenerate connections screenshot
Replace the static_names seeding (wrong model) with a pure reverse-DNS resolver: every address, local or public, is looked up through the system resolver and the result cached in the program-local map. On a router whose local DNS serves PTR for DHCP leases, private addresses resolve through DNS like any other. - Resolver takes an injectable 'lookup' callable (defaults to the real system PTR lookup); no static table - Demo provides demo_ptr_lookup() as a fake DNS backend for its synthetic addresses, exercising the same cache/queue path - App injects the demo backend only in --demo mode The static map never touched /etc/hosts (it was in-memory), but seeding names is the wrong approach regardless — DNS is the source of truth.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
v0.2.1 — fix connection endpoint resolution so both source and destination resolve on the WAN and LAN sub-tabs, using DNS only.
The problem
Both endpoints were already passed through the resolver, but resolution relied on reverse DNS (PTR), and private LAN addresses typically have no public PTR record. So the LAN tab showed only raw IPs, and WAN sources stayed numeric — it looked like the source column wasn't resolving.
The fix
Resolution is now pure reverse-DNS with a program-local cache — no static names table, no hosts file:
Resolverlooks every address (local or public) up through the system resolver and caches the result in its in-memory map, so each IP is resolved at most once. On a router whose local DNS serves PTR records for its DHCP leases, private addresses resolve through DNS like any other.Resolvertakes an injectablelookupcallable (defaults to the real system PTR lookup). This exists only so the synthetic--demomode can stand in a fake DNS backend for its fictional addresses — it is not a static map.--demo; production uses real DNS.Notes
/etc/hosts, but seeding names is the wrong model regardless).