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

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

This (new to me) ip thingy

Started byGene Heskett <gheskett@shentel.net>
First post2017-10-03 08:40 +0200
Last post2017-10-03 10:50 +0200
Articles 9 — 4 participants

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

Contents

  This (new to me) ip thingy Gene Heskett <gheskett@shentel.net> - 2017-10-03 08:40 +0200
    Re: This (new to me) ip thingy Reco <recoverym4n@gmail.com> - 2017-10-03 09:10 +0200
      Re: This (new to me) ip thingy Gene Heskett <gheskett@shentel.net> - 2017-10-03 10:10 +0200
        Re: This (new to me) ip thingy Reco <recoverym4n@gmail.com> - 2017-10-03 10:20 +0200
          Re: This (new to me) ip thingy Gene Heskett <gheskett@shentel.net> - 2017-10-03 10:40 +0200
            Re: This (new to me) ip thingy Reco <recoverym4n@gmail.com> - 2017-10-03 11:00 +0200
            Re: This (new to me) ip thingy <tomas@tuxteam.de> - 2017-10-03 11:10 +0200
              Re: This (new to me) ip thingy tomas@tuxteam.de - 2017-10-03 11:20 +0200
          Re: This (new to me) ip thingy Gene Heskett <gheskett@shentel.net> - 2017-10-03 10:50 +0200

#187515 — This (new to me) ip thingy

FromGene Heskett <gheskett@shentel.net>
Date2017-10-03 08:40 +0200
SubjectThis (new to me) ip thingy
Message-ID<uwp21-66O-1@gated-at.bofh.it>

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

Greetings;

Confusion still reigns here.
For instance:
oot@coyote:~# ip m l eth0
2:      eth0
        link  01:00:5e:00:00:01
        link  33:33:00:00:02:02
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:fb
        link  33:33:ff:62:fc:bb
        link  33:33:00:00:00:fb
        inet  224.0.0.251
        inet  224.0.0.1
        inet6 ff02::fb
        inet6 ff02::1:ff62:fcbb
        inet6 ff02::202
        inet6 ff02::1
        inet6 ff01::1

But add - -r so its supposed to show names, and get:
2:      eth0
        link  01:00:5e:00:00:01
        link  33:33:00:00:02:02
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:fb
        link  33:33:ff:62:fc:bb
        link  33:33:00:00:00:fb
        inet  (5 second pause) 224.0.0.251
        inet  all-systems.mcast.net
        inet6 ff02::fb
        inet6 ff02::1:ff62:fcbb
        inet6 ff02::202
        inet6 ip6-allnodes
        inet6 ff01::1
Which, according to the manpage and my interpretation, should resolv the names those 6 (mac?) addresses belong to.  So while its seemingly working at the net hardwares speed, I think its telling me I am miss-configured somehow. There are not any ipv6 addresses in the hosts file that would translate to the same name as the machines given name. I tried that several years ago and it caused errors at the time.

This is an all static local network, with dns provided by everything here pointed at the router for nameservice that's not in the hosts file, running dnsmasq, which in turn forwards any dns lookups it doesn't have the answer to cached, to my ISP's servers.

Shouldn't the -r version show FQDN's?  And why is it not?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

#187517

FromReco <recoverym4n@gmail.com>
Date2017-10-03 09:10 +0200
Message-ID<uwpv3-6v9-1@gated-at.bofh.it>
In reply to#187515
	Hi.

On Tue, Oct 03, 2017 at 02:32:29AM -0400, Gene Heskett wrote:
> Greetings;
> 
> Confusion still reigns here.
> For instance:
> oot@coyote:~# ip m l eth0
> 2:      eth0
>         link  01:00:5e:00:00:01
>         link  33:33:00:00:02:02
>         link  33:33:00:00:00:01
>         link  01:00:5e:00:00:fb
>         link  33:33:ff:62:fc:bb
>         link  33:33:00:00:00:fb
>         inet  224.0.0.251
>         inet  224.0.0.1
>         inet6 ff02::fb
>         inet6 ff02::1:ff62:fcbb
>         inet6 ff02::202
>         inet6 ff02::1
>         inet6 ff01::1

So, multicasts. Ok.

> But add - -r so its supposed to show names, and get:
> 2:      eth0
>         link  01:00:5e:00:00:01
>         link  33:33:00:00:02:02
>         link  33:33:00:00:00:01
>         link  01:00:5e:00:00:fb
>         link  33:33:ff:62:fc:bb
>         link  33:33:00:00:00:fb
>         inet  (5 second pause) 224.0.0.251
>         inet  all-systems.mcast.net
>         inet6 ff02::fb
>         inet6 ff02::1:ff62:fcbb
>         inet6 ff02::202
>         inet6 ip6-allnodes
>         inet6 ff01::1
> Which, according to the manpage and my interpretation, should resolv the names those 6 (mac?) addresses belong to.

No, it should not. It means:

-r, -resolve use the system's name resolver to print DNS names instead
of host addresses.

So, in plain English - if it is an IP address - it will be resolved.
If it is an IPv6 address - it will be resolved too.
At least ip will try to do so via /etc/hosts, DNS requests and other
name resolution methods all according to your /etc/nsswitch.conf.

To translate MACs to IPs you need to do ARP requests (ICMPv6 if you need
IPv6 addresses). Try "ip -r n s" instead.


> So while its seemingly working at the net hardwares speed, I think its telling me I am miss-configured somehow. There are not any ipv6 addresses in the hosts file that would translate to the same name as the machines given name. I tried that several years ago and it caused errors at the time.

Run "tcpdump -nvi any udp port 53 or tcp port 53 or udp port 5353".
Run "ip -r m l eth0" alongside with it.
Watch the result.

Frankly I'm not surprised that it failed to resolve 224.0.0.251. Nobody
sane would add a DNS record for this anyway.

Reco

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

#187519

FromGene Heskett <gheskett@shentel.net>
Date2017-10-03 10:10 +0200
Message-ID<uwqr7-72m-3@gated-at.bofh.it>
In reply to#187517
On Tuesday 03 October 2017 03:02:42 Reco wrote:

> ip -r n s
returns this unsorted list:
rock64Sheldon.coyote.den dev eth0 lladdr 3e:1b:98:17:e3:8c STALE
scanner.coyote.den dev eth0 lladdr 30:05:5c:8a:2d:c8 STALE
picnc.coyote.den dev eth0 lladdr b8:27:eb:d3:47:2d STALE
lathe.coyote.den dev eth0 lladdr 38:60:77:cd:f3:2f STALE
router.coyote.den dev eth0 lladdr 4c:e6:76:ad:34:0a STALE
GO704.coyote.den dev eth0 lladdr 00:1a:a0:a7:a8:d4 STALE
shop.coyote.den dev eth0 lladdr 38:60:77:4e:38:1b STALE

No clue why it should mark them all as stale except they've been up since 
the last power failure. This room is the only UPS and not all of it is 
on the UPS.  I also have a 20kw nat-gas standby in the backyard, so 
failures are just short enough to screw up the auto-reboot settings.

>Frankly I'm not surprised that it failed to resolve 224.0.0.251. Nobody
>sane would add a DNS record for this anyway.

I think thats from avahi, is definitely is not anything I have 
configured.

Scanner is also one of the printers, its an MFC, can do tabloid if I hand 
feed it.  Good for shrinking the page count of a rockhopper printout. 
Rockhopper can survey a running linuxcnc machine and give you a logic 
diagram of it.  Handier than that famous button on the outhouse door for 
troubleshooting a complex configuration. But its output, even on 11x17 
paper can run to 6 to 8 sheets that have to be pasted up into a poster.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#187520

FromReco <recoverym4n@gmail.com>
Date2017-10-03 10:20 +0200
Message-ID<uwqAN-75k-5@gated-at.bofh.it>
In reply to#187519
	Hi.

On Tue, Oct 03, 2017 at 04:04:56AM -0400, Gene Heskett wrote:
> On Tuesday 03 October 2017 03:02:42 Reco wrote:
> 
> > ip -r n s
> returns this unsorted list:
> rock64Sheldon.coyote.den dev eth0 lladdr 3e:1b:98:17:e3:8c STALE
> scanner.coyote.den dev eth0 lladdr 30:05:5c:8a:2d:c8 STALE
> picnc.coyote.den dev eth0 lladdr b8:27:eb:d3:47:2d STALE
> lathe.coyote.den dev eth0 lladdr 38:60:77:cd:f3:2f STALE
> router.coyote.den dev eth0 lladdr 4c:e6:76:ad:34:0a STALE
> GO704.coyote.den dev eth0 lladdr 00:1a:a0:a7:a8:d4 STALE
> shop.coyote.den dev eth0 lladdr 38:60:77:4e:38:1b STALE
> 
> No clue why it should mark them all as stale except they've been up since 
> the last power failure. This room is the only UPS and not all of it is 
> on the UPS.  I also have a 20kw nat-gas standby in the backyard, so 
> failures are just short enough to screw up the auto-reboot settings.

STALE has nothing to do with it. A typical ARP record (MAC-IP
correspondence) has very limited lifetime (30 seconds by default IIRC).
STALE shows you that this host haven't send any packets to these hosts
in last 30 seconds.

Also, ip-neighbour(8).


> >Frankly I'm not surprised that it failed to resolve 224.0.0.251. Nobody
> >sane would add a DNS record for this anyway.
> 
> I think thats from avahi, is definitely is not anything I have 
> configured.

Multicasts are not anything that *anyone* should configure.
The whole idea of them is that your L2 network segment configures by
itself.

Reco

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

#187521

FromGene Heskett <gheskett@shentel.net>
Date2017-10-03 10:40 +0200
Message-ID<uwqUa-7bo-13@gated-at.bofh.it>
In reply to#187520
On Tuesday 03 October 2017 04:17:49 Reco wrote:

> 	Hi.
>
> On Tue, Oct 03, 2017 at 04:04:56AM -0400, Gene Heskett wrote:
> > On Tuesday 03 October 2017 03:02:42 Reco wrote:
> > > ip -r n s
> >
> > returns this unsorted list:
> > rock64Sheldon.coyote.den dev eth0 lladdr 3e:1b:98:17:e3:8c STALE
> > scanner.coyote.den dev eth0 lladdr 30:05:5c:8a:2d:c8 STALE
> > picnc.coyote.den dev eth0 lladdr b8:27:eb:d3:47:2d STALE
> > lathe.coyote.den dev eth0 lladdr 38:60:77:cd:f3:2f STALE
> > router.coyote.den dev eth0 lladdr 4c:e6:76:ad:34:0a STALE
> > GO704.coyote.den dev eth0 lladdr 00:1a:a0:a7:a8:d4 STALE
> > shop.coyote.den dev eth0 lladdr 38:60:77:4e:38:1b STALE
> >
> > No clue why it should mark them all as stale except they've been up
> > since the last power failure. This room is the only UPS and not all
> > of it is on the UPS.  I also have a 20kw nat-gas standby in the
> > backyard, so failures are just short enough to screw up the
> > auto-reboot settings.
>
> STALE has nothing to do with it. A typical ARP record (MAC-IP
> correspondence) has very limited lifetime (30 seconds by default
> IIRC). STALE shows you that this host haven't send any packets to
> these hosts in last 30 seconds.
>
> Also, ip-neighbour(8).
>
> > >Frankly I'm not surprised that it failed to resolve 224.0.0.251.
> > > Nobody sane would add a DNS record for this anyway.
> >
> > I think thats from avahi, is definitely is not anything I have
> > configured.
>
> Multicasts are not anything that *anyone* should configure.
> The whole idea of them is that your L2 network segment configures by
> itself.
>
> Reco

In that class A? Not even my isp has anything there.  Its not a pingable 
address from here as I believe dd-wrt would stop it, nor does whois have 
a clue. NSA back door?  Damnifiknow. Traceroute gets zero response too.  
So what or who is it?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#187523

FromReco <recoverym4n@gmail.com>
Date2017-10-03 11:00 +0200
Message-ID<uwrdw-7hO-7@gated-at.bofh.it>
In reply to#187521
	Hi.

On Tue, Oct 03, 2017 at 04:36:12AM -0400, Gene Heskett wrote:

> > > >Frankly I'm not surprised that it failed to resolve 224.0.0.251.
> > > > Nobody sane would add a DNS record for this anyway.
> > >
> > > I think thats from avahi, is definitely is not anything I have
> > > configured.
> >
> > Multicasts are not anything that *anyone* should configure.
> > The whole idea of them is that your L2 network segment configures by
> > itself.
>
> In that class A?

Classful networks are obsolete. See RFC 4632.

> Not even my isp has anything there.

Mutlicasts are limited to a *local* network segment. Unless a black
magic called IGMP proxy is involved.

> Its not a pingable address from here as I believe dd-wrt would stop it, nor does whois have a clue.

Of course it's not pingable.
The whole point of 224.0.0.0/4 network is that there is no host that has
such addresses assigned, yet UDP packets should come to any host in a
*local* (in L2 sense) network segment. Assuming that said host wants to
listen such multicast address.

Also, RFC 1112.

> NSA back door?  Damnifiknow.

Nope. There's no point in such backdoor as multicasts are not routable.

> Traceroute gets zero response too.  

It should. Multicasts don't use ICMP.

Reco

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

#187524

From<tomas@tuxteam.de>
Date2017-10-03 11:10 +0200
Message-ID<uwrnb-7zY-9@gated-at.bofh.it>
In reply to#187521
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 03, 2017 at 04:36:12AM -0400, Gene Heskett wrote:
> On Tuesday 03 October 2017 04:17:49 Reco wrote:

[...]

> > Multicasts are not anything that *anyone* should configure.
> > The whole idea of them is that your L2 network segment configures by
> > itself.
> >
> > Reco
> 
> In that class A? Not even my isp has anything there.  Its not a pingable 
> address from here as I believe dd-wrt would stop it, nor does whois have 
> a clue. NSA back door?  Damnifiknow. Traceroute gets zero response too.  
> So what or who is it?

Reco's right. Have a look at [1], heck, spend an afternoon at your local
lib thumbing through R.L.Stevens "TCP/IP Illustrated". This afternoon
will pay for itself in terms of time within the next half-year, believe
me.

The address range 224.0.0.0/4 (in binary: 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx,
if my skills haven't betrayed me) is reserved for "IP multicast". One
source, many receivers. Think radio or TV broadcast. The sender sends
a packet once, and each router where traffic might split "knows" behind
which branch there are "interested" receivers (there's a protocol to
"register" interest). This router is then responsible for duplicating
packets. The idea is to not send the same packet 10000 times over the
same link.

Needless to say that even the idea of pinging such an address is
somewhat... mind bending :-)

Cheers
[1] https://en.wikipedia.org/wiki/IPV4#Special-use_addresses

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnTUzgACgkQBcgs9XrR2kac+gCdG+I3OEAFV7O74idsLO3RpurK
LqEAn3vjcsh+RYUBUPCga0z7sNR9gR/g
=Ckbk
-----END PGP SIGNATURE-----

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

#187525

Fromtomas@tuxteam.de
Date2017-10-03 11:20 +0200
Message-ID<uwrwR-7CZ-3@gated-at.bofh.it>
In reply to#187524
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 03, 2017 at 11:07:04AM +0200, tomas@tuxteam.de wrote:

[...]

Addendum: elsewhere in this thread, Avahi was mentioned. You'll find
this guy[1] in the same Wikipedia ref under "link local" addresses
(169.254.0.0/16). Those are "fairly normal" IP addresses, just that
the so-configured hosts will just grab them without you, the admin,
having given them permission to do so.

Cheers

[1] This is an oversimplification. Link local addresses are part of
zeroconf, and avahi is (part of) zeroconf's implementation. So they
are rather cousins, like Scylla [2] and Charybdis [3]

[2] https://en.wikipedia.org/wiki/Scylla
[3] https://en.wikipedia.org/wiki/Charybdis

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnTVgQACgkQBcgs9XrR2kYUVACfYTgAq0uLX9C8MofB+qZlIRE8
LbYAn0j52IhlU6eoe8yEeDq9MMaTReRV
=d9tb
-----END PGP SIGNATURE-----

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

#187522

FromGene Heskett <gheskett@shentel.net>
Date2017-10-03 10:50 +0200
Message-ID<uwr3P-7eu-7@gated-at.bofh.it>
In reply to#187520
On Tuesday 03 October 2017 04:17:49 Reco wrote:

> 	Hi.
>
> On Tue, Oct 03, 2017 at 04:04:56AM -0400, Gene Heskett wrote:
> > On Tuesday 03 October 2017 03:02:42 Reco wrote:
> > > ip -r n s
> >
> > returns this unsorted list:
> > rock64Sheldon.coyote.den dev eth0 lladdr 3e:1b:98:17:e3:8c STALE
> > scanner.coyote.den dev eth0 lladdr 30:05:5c:8a:2d:c8 STALE
> > picnc.coyote.den dev eth0 lladdr b8:27:eb:d3:47:2d STALE
> > lathe.coyote.den dev eth0 lladdr 38:60:77:cd:f3:2f STALE
> > router.coyote.den dev eth0 lladdr 4c:e6:76:ad:34:0a STALE
> > GO704.coyote.den dev eth0 lladdr 00:1a:a0:a7:a8:d4 STALE
> > shop.coyote.den dev eth0 lladdr 38:60:77:4e:38:1b STALE
> >
> > No clue why it should mark them all as stale except they've been up
> > since the last power failure. This room is the only UPS and not all
> > of it is on the UPS.  I also have a 20kw nat-gas standby in the
> > backyard, so failures are just short enough to screw up the
> > auto-reboot settings.
>
> STALE has nothing to do with it. A typical ARP record (MAC-IP
> correspondence) has very limited lifetime (30 seconds by default
> IIRC). STALE shows you that this host haven't send any packets to
> these hosts in last 30 seconds.
>
> Also, ip-neighbour(8).
>

> > >Frankly I'm not surprised that it failed to resolve 224.0.0.251.
> > > Nobody sane would add a DNS record for this anyway.
> >
> > I think thats from avahi, is definitely is not anything I have
> > configured.
>
> Multicasts are not anything that *anyone* should configure.
> The whole idea of them is that your L2 network segment configures by
> itself.
>
> Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [standalone]

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

csiph-web