iputil returns 0.0.0.0 #153
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#153
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I thought I was supposed to fix this, but I just saw it on cygwin.
Leaving this ticket here for myself to come back to it after I demo Tahoe to Seb.
Correction: it is the Solaris version of iputil that returns 0.0.0.0. The cygwin version doesn't.
So, if I just make iputil filter out all IP addresses that end in ".0", this will solve this issue, right? Is there any other filtering or munging that I should do?
(Note that iputil is intended to return non-routeable, private IP addresses, because foolscap can use those if both ends are on the same network and foolscap isn't harmed by them.)
actually, just filter out 0.0.0.0 . There are valid addresses that end in .0 (any subnet larger than /24 will have some host addresses that have 0 as a last octet).
0.0.0.0 is well-defined as a special "INADDR_ANY" address, and is never valid as a host address. So just filter out that one case.
Fixed by changeset:af0edec753033339.