Skip to content

Use now apparently maintained if-addrs #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

eskimor
Copy link
Contributor

@eskimor eskimor commented Sep 15, 2020

instead of unmaintained get-if-addrs.

instead of unmaintained get-if-addrs.
@eskimor eskimor changed the title Use now apparently maintained if-addrs WIP: Use now apparently maintained if-addrs Sep 16, 2020
@eskimor
Copy link
Contributor Author

eskimor commented Sep 16, 2020

This PR depends on a new release of if-addrs.

@eskimor
Copy link
Contributor Author

eskimor commented Sep 16, 2020

As far as I can see, all the build errors are already fixed on master of if-addrs, just waiting to be released.

@bltavares
Copy link
Owner

@eskimor I'm looking at the crate, and it does not seem to have any meaningful improvements over the fork. The last commits so far have been only renames of the crate from a few weeks ago.

I don't see any reason to change over to that dependency given it has no code change so far. I'd rather stay on a stable release until fixes/improvements appear on the fork.

@eskimor
Copy link
Contributor Author

eskimor commented Sep 17, 2020

Fair enough :-) I was planning on integrating your reverse patch there, but I don't see a problem waiting until that actually happens ;-) One minor thing though worth mentioning: The fork already bumped the winapi dependency, so that could be useful already.

@bltavares
Copy link
Owner

Oh, adding the reverse there would be great! It seems to have some new activity there. I would consider moving to the fork to remove the hotfix on mips 👍

@eskimor eskimor changed the title WIP: Use now apparently maintained if-addrs Use now apparently maintained if-addrs Sep 18, 2020
@mon
Copy link
Contributor

mon commented Mar 25, 2024

Bit of a necro, but I need support for link-local addresses, which the new if-addrs exposes as a feature. Can this PR be resurrected?

@mon
Copy link
Contributor

mon commented Mar 25, 2024

There's actually some more code required as I have 3 link-local addresses on my machine, and two of them are actually disconnected and fail with ErrorKind::AddrNotAvailable. Worth just making my own PR with the new if_addrs and the other required handling for this case?

@bltavares
Copy link
Owner

Sure thing, I'd consider replacing the lib if the MIPS support have been merged, which was the blocker last time.

@mon
Copy link
Contributor

mon commented Mar 31, 2024

Truthfully, I can't tell if they fixed the MIPS issue yet - do you have a MIPS system to test it on? I've never touched that arch.

@bltavares
Copy link
Owner

Yes, I do have some mips routers to test, and the CI should check for compilation at least.

@mon
Copy link
Contributor

mon commented Mar 31, 2024

I looked a little more intently - the old MIPS bug is caused by a manual sockaddr parse:
https://github.com/maidsafe-archive/get_if_addrs/blob/master/src/sockaddr.rs#L37-L43

The new one uses to_ne_bytes, which will be big-endian aware:
https://github.com/messense/if-addrs/blob/master/src/sockaddr.rs#L42

I'll start work on the re-port :)

@bltavares
Copy link
Owner

Thanks for the interest @mon :) Let me know how it goes, and I can test on a device later

@bltavares
Copy link
Owner

Closed by #19

@bltavares bltavares closed this Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants