Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205373 > unrolled thread

get my ip address

Back to article view | Back to linux.debian.user

Contents

  get my ip address tony <lists@vanderhoff.org> - 2019-02-15 11:40 +0100
    Re: get my ip address <tomas@tuxteam.de> - 2019-02-15 11:50 +0100
    Re: get my ip address Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2019-02-15 12:10 +0100
      Re: get my ip address David Wright <deblis@lionunicorn.co.uk> - 2019-02-15 17:00 +0100
        Re: get my ip address David Wright <deblis@lionunicorn.co.uk> - 2019-02-16 01:00 +0100
          Re: get my ip address John Crawley <john@bunsenlabs.org> - 2019-02-16 03:20 +0100
            Re: get my ip address David Wright <deblis@lionunicorn.co.uk> - 2019-02-16 06:30 +0100
              Re: get my ip address John Crawley <john@bunsenlabs.org> - 2019-02-17 05:00 +0100
                Re: get my ip address David Wright <deblis@lionunicorn.co.uk> - 2019-02-20 05:40 +0100
        Re: get my ip address tony <lists@vanderhoff.org> - 2019-02-16 11:20 +0100
          Re: get my ip address David Wright <deblis@lionunicorn.co.uk> - 2019-02-20 05:40 +0100
    Re: get my ip address Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-19 16:20 +0100
      Re: get my ip address tony <lists@vanderhoff.org> - 2019-02-19 16:50 +0100
        Re: get my ip address Dan Ritter <dsr@randomstring.org> - 2019-02-19 17:40 +0100
          Re: get my ip address tony <lists@vanderhoff.org> - 2019-02-19 18:10 +0100
          Re: get my ip address Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-19 18:10 +0100
          Re: get my ip address tony <lists@vanderhoff.org> - 2019-02-20 11:40 +0100
            Re: get my ip address Dan Ritter <dsr@randomstring.org> - 2019-02-20 13:30 +0100
              Re: get my ip address tony <lists@vanderhoff.org> - 2019-02-20 14:00 +0100
    Re: get my ip address Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2019-02-28 15:40 +0100

#205373 — get my ip address

Hi all,

Debian 9. I need to read my IPv6 address into a python script.

I am aware that I can call ip a and parse the result. The parsing,
whilst quite achievable, is slightly tricky, but I can manage the RE, so
 that's not my question.

Is there any other way to obtain this data, maybe from /sys?

Cheers, Tony.

[toc] | [next] | [standalone]

#205374

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
> Hi all,
> 
> Debian 9. I need to read my IPv6 address into a python script.

You don't have "an IP address". Your host has, and it has zero or
more (potentially many) IP addresses. With IPV6, you'll almost
certainly end up with more than one per interface.

> I am aware that I can call ip a and parse the result. The parsing,
> whilst quite achievable, is slightly tricky, but I can manage the RE, so
>  that's not my question.
> 
> Is there any other way to obtain this data, maybe from /sys?

Try a DuckDuckGo search for ["IP address" site:docs.python.org/3]

Here [1] is a link for your convenience.

Cheers
[1] https://duckduckgo.com/html?q=%22IP%20address%22+site:docs.python.org/3
-- tomás

[toc] | [prev] | [next] | [standalone]

#205376

Tony, 15.2.2019, 11:11:29 +0100:

> Debian 9. I need to read my IPv6 address into a python script.
> 
> I am aware that I can call ip a and parse the result. The parsing,
> whilst quite achievable, is slightly tricky, but I can manage the RE, so
>  that's not my question.
> 
> Is there any other way to obtain this data, maybe from /sys?

Take a look at this:
https://pypi.org/project/netifaces/

This is packaged on stretch as python[3]-netifaces

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#205387

On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
> Tony, 15.2.2019, 11:11:29 +0100:
> 
> > Debian 9. I need to read my IPv6 address into a python script.
> > 
> > I am aware that I can call ip a and parse the result. The parsing,
> > whilst quite achievable, is slightly tricky, but I can manage the RE, so
> >  that's not my question.
> > 
> > Is there any other way to obtain this data, maybe from /sys?
> 
> Take a look at this:
> https://pypi.org/project/netifaces/
> 
> This is packaged on stretch as python[3]-netifaces

That's probably best if your destination is a Python program.

Otherwise, for scripting, it's easy to overlook   ip -o a
which makes parsing much easier. But note that you may then
need to be more specific, eg compare

$ ip a

with

$ ip -o l
$ ip -o a

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205410

On Fri 15 Feb 2019 at 22:04:42 (+0000), Darac Marjal wrote:
> If you're going to recommend parsing `ip`, the -j option may be more
> amenable to scripting. (JSON output)
> 
> On 15/02/2019 15:52, David Wright wrote:
> > On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
> >> Tony, 15.2.2019, 11:11:29 +0100:
> >>
> >>> Debian 9. I need to read my IPv6 address into a python script.
             ↑
Some of us here are still running stable (stretch) and older. So
perhaps only for buster onwards and, I assume, stretch-backports.
But …

> > [That's probably best if your destination is a Python program. ←snipped]

> > Otherwise, for scripting, it's easy to overlook   ip -o a
> > which makes parsing much easier.

(Sorry if I was expected to explicitly write "shell scripting".)
… I don't think that JSON would be any help: rather, the opposite.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205415

On 16/02/2019 08.54, David Wright wrote:
> On Fri 15 Feb 2019 at 22:04:42 (+0000), Darac Marjal wrote:
>> If you're going to recommend parsing `ip`, the -j option may be more
>> amenable to scripting. (JSON output)
>>
>> On 15/02/2019 15:52, David Wright wrote:
>>> On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
>>>> Tony, 15.2.2019, 11:11:29 +0100:
>>>>
>>>>> Debian 9. I need to read my IPv6 address into a python script.
>               ↑
> Some of us here are still running stable (stretch) and older. So
> perhaps only for buster onwards and, I assume, stretch-backports.
> But …
> 
>>> [That's probably best if your destination is a Python program. ←snipped]
> 
>>> Otherwise, for scripting, it's easy to overlook   ip -o a
>>> which makes parsing much easier.
> 
> (Sorry if I was expected to explicitly write "shell scripting".)
> … I don't think that JSON would be any help: rather, the opposite.

Though a call to jq makes parsing json very easy for shell scripts.

-- 
John

[toc] | [prev] | [next] | [standalone]

#205419

On Sat 16 Feb 2019 at 11:10:32 (+0900), John Crawley wrote:
> On 16/02/2019 08.54, David Wright wrote:
> > On Fri 15 Feb 2019 at 22:04:42 (+0000), Darac Marjal wrote:
> > > If you're going to recommend parsing `ip`, the -j option may be more
> > > amenable to scripting. (JSON output)
> > > 
> > > On 15/02/2019 15:52, David Wright wrote:
> > > > On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
> > > > > Tony, 15.2.2019, 11:11:29 +0100:
> > > > > 
> > > > > > Debian 9. I need to read my IPv6 address into a python script.
> >                ↑
> > Some of us here are still running stable (stretch) and older. So
> > perhaps only for buster onwards and, I assume, stretch-backports.
> > But …
> > 
> > > > [That's probably best if your destination is a Python program. ←snipped]
> > 
> > > > Otherwise, for scripting, it's easy to overlook   ip -o a
> > > > which makes parsing much easier.
> > 
> > (Sorry if I was expected to explicitly write "shell scripting".)
> > … I don't think that JSON would be any help: rather, the opposite.
> 
> Though a call to jq makes parsing json very easy for shell scripts.

I'm not sure I understand why you'd ask ip to write JSON, and then
post-process it with jq to filter it to different JSON, and then
parse it in a shell, rather than just parsing something as simple as
the oneline format using the tools that every system has installed
(like grep, sed).

That is, unless you're already involving jq for something else,
like the OP is with their Python program. And as we've seen, Python
has a module or function for just about everything, and may avoid
having to call ip in the first place.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205452

On 16/02/2019 14.28, David Wright wrote:
> On Sat 16 Feb 2019 at 11:10:32 (+0900), John Crawley wrote:
>> On 16/02/2019 08.54, David Wright wrote:
>>> On Fri 15 Feb 2019 at 22:04:42 (+0000), Darac Marjal wrote:
>>>> If you're going to recommend parsing `ip`, the -j option may be more
>>>> amenable to scripting. (JSON output)
---
>>> (Sorry if I was expected to explicitly write "shell scripting".)
>>> … I don't think that JSON would be any help: rather, the opposite.
>>
>> Though a call to jq makes parsing json very easy for shell scripts.
> 
> I'm not sure I understand why you'd ask ip to write JSON, and then
> post-process it with jq to filter it to different JSON, and then
> parse it in a shell, rather than just parsing something as simple as
> the oneline format using the tools that every system has installed

jq can pull out the exact element of the json that you want, making 
further shell parsing unnecessary.
Totally unrelated example, (Adobe flash player downloads)
this query:
curl -s 
"https://get.adobe.com/flashplayer/webservices/json/?platform_type=Linux&platform_arch=x86-32&browser_dist=Chrome" 
| jq -r '.[0].download_url'
returns:
http://fpdownload.adobe.com/pub/flashplayer/pdc/32.0.0.142/flash_player_ppapi_linux.i386.tar.gz

-- 
John

[toc] | [prev] | [next] | [standalone]

#205534

On Sun 17 Feb 2019 at 12:51:34 (+0900), John Crawley wrote:
> On 16/02/2019 14.28, David Wright wrote:
> > On Sat 16 Feb 2019 at 11:10:32 (+0900), John Crawley wrote:
> > > On 16/02/2019 08.54, David Wright wrote:
> > > > On Fri 15 Feb 2019 at 22:04:42 (+0000), Darac Marjal wrote:
> > > > > If you're going to recommend parsing `ip`, the -j option may be more
> > > > > amenable to scripting. (JSON output)
> ---
> > > > (Sorry if I was expected to explicitly write "shell scripting".)
> > > > … I don't think that JSON would be any help: rather, the opposite.
> > > 
> > > Though a call to jq makes parsing json very easy for shell scripts.
> > 
> > I'm not sure I understand why you'd ask ip to write JSON, and then
> > post-process it with jq to filter it to different JSON, and then
> > parse it in a shell, rather than just parsing something as simple as
> > the oneline format using the tools that every system has installed
> 
> jq can pull out the exact element of the json that you want, making
> further shell parsing unnecessary.
> Totally unrelated example, (Adobe flash player downloads)
> this query:
> curl -s "https://get.adobe.com/flashplayer/webservices/json/?platform_type=Linux&platform_arch=x86-32&browser_dist=Chrome"
> | jq -r '.[0].download_url'
> returns:
> http://fpdownload.adobe.com/pub/flashplayer/pdc/32.0.0.142/flash_player_ppapi_linux.i386.tar.gz

It's a very different example from what the OP was talking about. But
I am interested to know where the [0] came from in your jq options.

It's also a very different example from what I use   ip -o   for,
which is to pick up the name of my own wired interface and the
ipv6 address of whatever machine is connected to the other end of
a cat5 cable. The results are used for the purpose, much disapproved
of by certain people here, of directly connecting two hosts and using
the ipv6 link to transfer files, thereby leaving both machines' ipv4
configuration completely undisturbed.

My script fragments are:

 Mywiredifname=$(ip -o link show | sed -e '/^[0-9]\+: [^e]/d;s/[0-9]\+: \([^:]\+\): .*/\1/;')

where sed throws away any interface names not starting with "e" and
then prints the rest. (All my machines nowadays have one wired port,
so multiple lines never occur.)

 ping6 -c 1 -W 1 ff02::1%"$Mywiredifname"
 Neighbour=$(ip -6 -o neighbour | sed -e 's/^\([^ ]\+\) .*/\1/;')

where sed throws away everything after the first space.
So now I have the ipv6 address of the interface at the other end,
and I can login or transfer files with a single bash function that
isn't aware of the hostnames at either end.

This ping, for example, checks whether the machine is still connected¹
at the other end (neighbour entries can be stale) before proceeding:

 ping6 -c 1 -W 1 "$Neighbour%$Mywiredifname" # and test $?

You're welcome to rewrite these fragments using json, and I shall
try them out.

¹ I have the odd cat5 connector where the locking tab has snapped off.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205434

On 15/02/2019 16:52, David Wright wrote:
> On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
>> Tony, 15.2.2019, 11:11:29 +0100:
>>
>>> Debian 9. I need to read my IPv6 address into a python script.
>>>
>>> I am aware that I can call ip a and parse the result. The parsing,
>>> whilst quite achievable, is slightly tricky, but I can manage the RE, so
>>>  that's not my question.
>>>
>>> Is there any other way to obtain this data, maybe from /sys?
>>
>> Take a look at this:
>> https://pypi.org/project/netifaces/
>>
>> This is packaged on stretch as python[3]-netifaces
> 
> That's probably best if your destination is a Python program.
> 
> Otherwise, for scripting, it's easy to overlook   ip -o a
> which makes parsing much easier. But note that you may then
> need to be more specific, eg compare
> 
> $ ip a
> 
> with
> 
> $ ip -o l
> $ ip -o a


Thanks to all who replied, I hadn't expected pointers to the various
python libraries, for which I am very grateful. All I asked for was a
simple way of directly accessing the hardware, but that does not seem to
be available.

Failing that, I had indeed overlooked the -o flag oo ip a, which indeed
makes parsing easier. However, it does appear that netifaces offers  the
most usable solution, so a cigar to David Wright for this suggestion.

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#205533

On Sat 16 Feb 2019 at 11:16:23 (+0100), tony wrote:
> On 15/02/2019 16:52, David Wright wrote:
> > On Fri 15 Feb 2019 at 12:02:20 (+0100), Markus Schönhaber wrote:
> >> Tony, 15.2.2019, 11:11:29 +0100:
> >>
> >>> Debian 9. I need to read my IPv6 address into a python script.
> >>>
> >>> I am aware that I can call ip a and parse the result. The parsing,
> >>> whilst quite achievable, is slightly tricky, but I can manage the RE, so
> >>>  that's not my question.
> >>>
> >>> Is there any other way to obtain this data, maybe from /sys?
> >>
> >> Take a look at this:
> >> https://pypi.org/project/netifaces/
> >>
> >> This is packaged on stretch as python[3]-netifaces
> > 
> > That's probably best if your destination is a Python program.
> > 
> > Otherwise, for scripting, it's easy to overlook   ip -o a
> > which makes parsing much easier. But note that you may then
> > need to be more specific, eg compare
> > 
> > $ ip a
> > 
> > with
> > 
> > $ ip -o l
> > $ ip -o a
> 
> 
> Thanks to all who replied, I hadn't expected pointers to the various
> python libraries, for which I am very grateful. All I asked for was a
> simple way of directly accessing the hardware, but that does not seem to
> be available.
> 
> Failing that, I had indeed overlooked the -o flag oo ip a, which indeed
> makes parsing easier. However, it does appear that netifaces offers  the
> most usable solution, so a cigar to David Wright for this suggestion.

I only quoted netifaces, so Markus Schönhaber deserves the cigar.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205519

On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
> Debian 9. I need to read my IPv6 address into a python script.

Why?

<https://mywiki.wooledge.org/IpAddress> may offer some insight.

[toc] | [prev] | [next] | [standalone]

#205520

On 19/02/2019 16:10, Greg Wooledge wrote:
> On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
>> Debian 9. I need to read my IPv6 address into a python script.
> 
> Why?
> 
> <https://mywiki.wooledge.org/IpAddress> may offer some insight.
> 

Well, I'm sure you don't really want to know, and I don't think your
blog covers my use case. Correct me if I'm wrong on either count.

I have a network of IoTs consisting of 5 (I think) Paspberry Pis,
monitoring various things, and periodically sending the data to my VPS.
I need access to these hosts to manage them.

The network supplier is Orange France (spit!) who supply a dynamic DNS
on both IPv4 and IPv6. I need to access any of them. For some years, I
have been using NAT over IPv4 with some success. I simply collect the
router's address from the server using curl, compare it with the current
DNS setting, and run nsupdate if different.

Now, Orange (spit!) have recently discovered. IPv6, which makes
management much easier, so I'm in the process of changing over to that
protocol. Sadly the prefix is dynamic; ${deity} knows why. Each host
address is set up from router advertisement, so I figure I only need to
catch the host's current address, and set up the DNS accordingly. I'm
successfully doing that manually, but, of course, that's not very
satisfactory.

See - I told you it wasn't worth knowing!


Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#205523

tony wrote: 
> On 19/02/2019 16:10, Greg Wooledge wrote:
> > On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
> >> Debian 9. I need to read my IPv6 address into a python script.
> > 
> > Why?
> > 
> > <https://mywiki.wooledge.org/IpAddress> may offer some insight.
> > 
> 
> Well, I'm sure you don't really want to know, and I don't think your
> blog covers my use case. Correct me if I'm wrong on either count.
> 
> I have a network of IoTs consisting of 5 (I think) Paspberry Pis,
> monitoring various things, and periodically sending the data to my VPS.
> I need access to these hosts to manage them.
> 
> The network supplier is Orange France (spit!) who supply a dynamic DNS
> on both IPv4 and IPv6. I need to access any of them. For some years, I
> have been using NAT over IPv4 with some success. I simply collect the
> router's address from the server using curl, compare it with the current
> DNS setting, and run nsupdate if different.
> 
> Now, Orange (spit!) have recently discovered. IPv6, which makes
> management much easier, so I'm in the process of changing over to that
> protocol. Sadly the prefix is dynamic; ${deity} knows why. Each host
> address is set up from router advertisement, so I figure I only need to
> catch the host's current address, and set up the DNS accordingly. I'm
> successfully doing that manually, but, of course, that's not very
> satisfactory.

That sounds like a job for a dynamic dns client.

existing Debian packages:

ddclient (multiple backend services supported)
ddupdate (also supports multiple services, more plugin-oriented)
dyfi  (Finnish users only)
dyndns   (multiple services)
ez-ipupdate (multiple services)
ipcheck (dyndns protocol specific, but many services use it)
isc-dhcp-client-ddns  (adds dynamic dns to DHCP)

Don't reinvent the wheel, when it looks like it already has
seven versions already.

-dsr-

[toc] | [prev] | [next] | [standalone]

#205524

On 19/02/2019 17:36, Dan Ritter wrote:
> tony wrote: 
>> On 19/02/2019 16:10, Greg Wooledge wrote:
>>> On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
>>>> Debian 9. I need to read my IPv6 address into a python script.
>>>
>>> Why?
>>>
>>> <https://mywiki.wooledge.org/IpAddress> may offer some insight.
>>>
>>
>> Well, I'm sure you don't really want to know, and I don't think your
>> blog covers my use case. Correct me if I'm wrong on either count.
>>
>> I have a network of IoTs consisting of 5 (I think) Paspberry Pis,
>> monitoring various things, and periodically sending the data to my VPS.
>> I need access to these hosts to manage them.
>>
>> The network supplier is Orange France (spit!) who supply a dynamic DNS
>> on both IPv4 and IPv6. I need to access any of them. For some years, I
>> have been using NAT over IPv4 with some success. I simply collect the
>> router's address from the server using curl, compare it with the current
>> DNS setting, and run nsupdate if different.
>>
>> Now, Orange (spit!) have recently discovered. IPv6, which makes
>> management much easier, so I'm in the process of changing over to that
>> protocol. Sadly the prefix is dynamic; ${deity} knows why. Each host
>> address is set up from router advertisement, so I figure I only need to
>> catch the host's current address, and set up the DNS accordingly. I'm
>> successfully doing that manually, but, of course, that's not very
>> satisfactory.
> 
> That sounds like a job for a dynamic dns client.
> 
> existing Debian packages:
> 
> ddclient (multiple backend services supported)
> ddupdate (also supports multiple services, more plugin-oriented)
> dyfi  (Finnish users only)
> dyndns   (multiple services)
> ez-ipupdate (multiple services)
> ipcheck (dyndns protocol specific, but many services use it)
> isc-dhcp-client-ddns  (adds dynamic dns to DHCP)
> 
> Don't reinvent the wheel, when it looks like it already has
> seven versions already.
> 
> -dsr-
> 

Thanks, I'll take a look.

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#205525

On Tue, Feb 19, 2019 at 11:36:49AM -0500, Dan Ritter wrote:
> tony wrote: 
> > I have a network of IoTs consisting of 5 (I think) Paspberry Pis,
> > monitoring various things, and periodically sending the data to my VPS.
> > I need access to these hosts to manage them.
> > 
> > The network supplier is Orange France (spit!) who supply a dynamic DNS
> > on both IPv4 and IPv6. I need to access any of them.

> That sounds like a job for a dynamic dns client.

Agreed.

> existing Debian packages:
> 
> ddclient (multiple backend services supported)
> ddupdate (also supports multiple services, more plugin-oriented)
> dyfi  (Finnish users only)
> dyndns   (multiple services)
> ez-ipupdate (multiple services)
> ipcheck (dyndns protocol specific, but many services use it)
> isc-dhcp-client-ddns  (adds dynamic dns to DHCP)

And the specific case of dynamic DNS updates is definitely covered
on the wiki page that I linked (https://mywiki.wooledge.org/IpAddress).
It even has sample code for Debian 8.

If you need to use a special python dynamic DNS client for some reason,
that's fine.  Just hook it from the dhclient-exit-hooks.d directory and
let it use the new_ip_address environment variable.  The example is
right there on the wiki page.  Just replace /usr/local/sbin/dync with
your python program (assuming it takes the IP address on the argument list).

Oh... wait, you said IPv6 in the original message, right?  Ugh.  I don't
know IPv6 myself, but fortunately we can look that up... um, somewhere!

wooledg:~$ man dhclient-script | grep 6
       $new_dhcp6_server_id.  The options that the client explicitly requested

... OK, apparently not *there*.

But looking through /sbin/dhclient-script itself, there appear to be
the following variables:

new_ip6_address
new_dhcp6_name_servers
new_dhcp5_domain_search

Maybe those will help?  Give it a shot.  Or wait for someone who knows IPv6
to chime in.

[toc] | [prev] | [next] | [standalone]

#205545

On 19/02/2019 17:36, Dan Ritter wrote:
> tony wrote: 
>> On 19/02/2019 16:10, Greg Wooledge wrote:
>>> On Fri, Feb 15, 2019 at 11:11:29AM +0100, tony wrote:
>>>> Debian 9. I need to read my IPv6 address into a python script.
>>>
>>> Why?
>>>
>>> <https://mywiki.wooledge.org/IpAddress> may offer some insight.

> That sounds like a job for a dynamic dns client.
> 
> existing Debian packages:
> 
> ddclient (multiple backend services supported)
> ddupdate (also supports multiple services, more plugin-oriented)
> dyfi  (Finnish users only)
> dyndns   (multiple services)
> ez-ipupdate (multiple services)
> ipcheck (dyndns protocol specific, but many services use it)
> isc-dhcp-client-ddns  (adds dynamic dns to DHCP)
> 
> Don't reinvent the wheel, when it looks like it already has
> seven versions already.
> 

Right, I've had a (brief) look at some of those, and it seems to me that
none offer a better solution than what I've already got.

This thread has now drifted from my asking whether there was any way of
interrogating the hardware to obtain the current IP6 address of host -
apparently not - via an outburst of pedantry, to recommendations on some
off the shelf libraries to update a DNS. I have no problem; I was simply
investigating alternatives to obtaining the current IP6 address, and
thanks to an early reply came up with netifaces, which does a fine job.

As I previously mentioned, I have a well-tried program for keeping my
DNS updated - albeit for IP4 only, and all I want is to extend that for
IP6. Re-inventing the wheel? No, just a natural evolution. I'd be
re-inventing the wheel if I scrapped what I've got, simply to use a
general-purpose library.

If I were starting from scratch, I may well consider a ready-made
client. One drawback that is immediately apparent, and may well be a
misunderstanding on my part, is that any of the clients mentioned
require to be configured with a particular (proprietary) protocol, to
communicate with a (proprietary) dynamic DNS server (DynDNS seems to be
the favourite). Nowhere have I seen NSUpdate mentioned. Maybe there's a
reason for that, but I'm quite happy with NSUpdate.

So, whilst I appreciate all your attempts to help, I think I'll stick
with what I've got.

Thanks all.

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#205548

tony wrote: 
> This thread has now drifted from my asking whether there was any way of
> interrogating the hardware to obtain the current IP6 address of host -
> apparently not 

The hardware doesn't know IP addresses. The kernel knows those.

$ ip -6 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
qlen 1000
    inet6 2001:470:1e07:ff7:d63d:7eff:fe93:e318/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::d63d:7eff:fe93:e318/64 scope link
       valid_lft forever preferred_lft forever

$ ip -6 r show | grep eth0
2001:470:1e07:ff7::/64 dev eth0 proto kernel metric 256  pref
medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium

Tra-la.

Didn't you get this answer before?

-dsr-

[toc] | [prev] | [next] | [standalone]

#205549

On 20/02/2019 13:24, Dan Ritter wrote:
> tony wrote: 
>> This thread has now drifted from my asking whether there was any way of
>> interrogating the hardware to obtain the current IP6 address of host -
>> apparently not 
> 
> The hardware doesn't know IP addresses. The kernel knows those.
> 
> $ ip -6 a show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
> qlen 1000
>     inet6 2001:470:1e07:ff7:d63d:7eff:fe93:e318/64 scope global
>        valid_lft forever preferred_lft forever
>     inet6 fe80::d63d:7eff:fe93:e318/64 scope link
>        valid_lft forever preferred_lft forever
> 
> $ ip -6 r show | grep eth0
> 2001:470:1e07:ff7::/64 dev eth0 proto kernel metric 256  pref
> medium
> fe80::/64 dev eth0 proto kernel metric 256  pref medium
> 
> Tra-la.
> 
> Didn't you get this answer before?
> 
> -dsr-
> 

Many times.

[toc] | [prev] | [next] | [standalone]

#205820

tony;
> I am aware that I can call ip a and parse the result. [...]
>
> Is there any other way to obtain this data, maybe from /sys?

just call libc.getifaddrs() directly.

* 
http://programmaticallyspeaking.com./getting-network-interfaces-in-python.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web