Getting local IP addresses from emacs

Getting local IP addresses from emacs

[Robert Pluim]

Hi,

thereʼs code in nsm.el conditioned on 'nsm-trust-local-network' that
depends on knowing what the local IP addresses are. Unfortunately
'network-interface-list'

a. Doesnʼt actually list all the network interfaces
b. Only provides IPv4 addresses
c. Doesnʼt return netmask information

'network-interface-info' does provide netmask information, but only
for IPv4 (and it uses syscalls that canʼt be used for IPv6).

I was thinking of reworking 'network-interface-list' to use
'getifaddrs' instead of the ioctls it does now, which would get all
the interfaces, and (optionally) return the netmask/broadcast
info. The only issue there is that the returned interface names would
no longer be unique.

Of course this is all POSIX-only, MSWindows has similar APIs to
getifaddrs, but as far as I can tell they only exist from XP onwards,
so Iʼd need someone's help there.

Proposed docstring below (the default output would be identical in
format to the current one, just with potentially more entries).

    DEFUN ("network-interface-list", Fnetwork_interface_list,
           Snetwork_interface_list, 0, 2, 0,
           doc: /* Return an alist of all network interfaces and their network address.
    Each element is cons of the form (IFNAME . IP) where IFNAME is a
    string containing the interface name, and IP is the network address in
    internal format; see the description of ADDRESS in
    `make-network-process'.  The interface name is not guaranteed to be
    unique.

    Optional parameter FULL non-nil means return all IP address info for
    each interface.  Each element is then a list of the form
        (IFNAME IP BCAST MASK)
    where IFNAME is the interface name, IP the IP address,
    BCAST the broadcast address, and MASK the network mask.

    Optional parameter FAMILY controls the type of addresses to return.
    The default of nil means both IPv4 and IPv6, symbol `ipv4' means IPv4
    only, symbol `ipv6' means IPv6 only.

    See also `network-interface-info', and `network-interface-list', which
    are limited to IPv4 only.

    If the information is not available, return nil.  */)
      (Lisp_Object full, Lisp_Object family)

Re: Getting local IP addresses from emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I was thinking of reworking 'network-interface-list' to use
> 'getifaddrs' instead of the ioctls it does now, which would get all
> the interfaces, and (optionally) return the netmask/broadcast
> info.

Sounds like a good idea to me.

> The only issue there is that the returned interface names would
> no longer be unique.

Under what circumstances wouldn't the names be unique?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Getting local IP addresses from emacs

[Robert Pluim]

>>>>> On Fri, 08 Nov 2019 21:39:04 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> I was thinking of reworking 'network-interface-list' to use
    >> 'getifaddrs' instead of the ioctls it does now, which would get all
    >> the interfaces, and (optionally) return the netmask/broadcast
    >> info.

    Lars> Sounds like a good idea to me.

    >> The only issue there is that the returned interface names would
    >> no longer be unique.

    Lars> Under what circumstances wouldn't the names be unique?

You get one entry per address, but the name is always that of the
underlying interface, so on your typical IPv4/v6 dual stack machine
you get stuff like:

 ("lo0" .
  [0 0 0 0 0 0 0 1 0])
 ("lo0" .
  [127 0 0 1 0])

Re: Getting local IP addresses from emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> You get one entry per address, but the name is always that of the
> underlying interface, so on your typical IPv4/v6 dual stack machine
> you get stuff like:
>
>  ("lo0" .
>   [0 0 0 0 0 0 0 1 0])
>  ("lo0" .
>   [127 0 0 1 0])

Ah, I think that's fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Getting local IP addresses from emacs

[Robert Pluim]

>>>>> On Fri, 08 Nov 2019 22:24:41 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> You get one entry per address, but the name is always that of the
    >> underlying interface, so on your typical IPv4/v6 dual stack machine
    >> you get stuff like:
    >> 
    >> ("lo0" .
    >> [0 0 0 0 0 0 0 1 0])
    >> ("lo0" .
    >> [127 0 0 1 0])

So I have a working implementation of this, including a cargo-culted
MSWindows version. Should I post the patch here, or would people
prefer a scratch branch? (the patch is ~600 lines).

Robert

Re: Getting local IP addresses from emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> Date: Thu, 14 Nov 2019 10:22:50 +0100
> 
> So I have a working implementation of this, including a cargo-culted
> MSWindows version. Should I post the patch here, or would people
> prefer a scratch branch? (the patch is ~600 lines).

A branch will preserve history, assuming you will "git merge" when
it's done.  But if you intend to rebase before landing, then it
doesn't matter, and you can do whatever you prefer.

Thanks.

Re: Getting local IP addresses from emacs

[Robert Pluim]

>>>>> On Thu, 14 Nov 2019 16:07:32 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org, eliz@gnu.org
    >> Date: Thu, 14 Nov 2019 10:22:50 +0100
    >> 
    >> So I have a working implementation of this, including a cargo-culted
    >> MSWindows version. Should I post the patch here, or would people
    >> prefer a scratch branch? (the patch is ~600 lines).

    Eli> A branch will preserve history, assuming you will "git merge" when
    Eli> it's done.  But if you intend to rebase before landing, then it
    Eli> doesn't matter, and you can do whatever you prefer.

I invariably rebase for single-issue branches. I was asking because
for bigger changes some people prefer reviewing an email, and some
prefer git.

Robert

Re: Getting local IP addresses from emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 14 Nov 2019 15:44:21 +0100
> 
>     Eli> A branch will preserve history, assuming you will "git merge" when
>     Eli> it's done.  But if you intend to rebase before landing, then it
>     Eli> doesn't matter, and you can do whatever you prefer.
> 
> I invariably rebase for single-issue branches. I was asking because
> for bigger changes some people prefer reviewing an email, and some
> prefer git.

For me, it doesn't matter.  But maybe someone else will have
preferences.

Re: Getting local IP addresses from emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I invariably rebase for single-issue branches. I was asking because
>> for bigger changes some people prefer reviewing an email, and some
>> prefer git.
>
> For me, it doesn't matter.  But maybe someone else will have
> preferences.

I think posting the patch is handy because then the change is right
there in the bug tracker.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Getting local IP addresses from emacs

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 08:49:11 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Eli Zaretskii <eliz@gnu.org> writes:
    >>> I invariably rebase for single-issue branches. I was asking because
    >>> for bigger changes some people prefer reviewing an email, and some
    >>> prefer git.
    >> 
    >> For me, it doesn't matter.  But maybe someone else will have
    >> preferences.

    Lars> I think posting the patch is handy because then the change is right
    Lars> there in the bug tracker.

Thereʼs a bug for this? Or do you want me to open one?

Robert

Re: Getting local IP addresses from emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Thereʼs a bug for this? Or do you want me to open one?

Sorry; I thought I was looking at a bug report.  But, yes, tying changes
like this to a bug report is nice for future trackability. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no