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

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

Is there a way to know the ISP with the default installation of Stretch?

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

Contents

  Is there a way to know the ISP with the default installation of  Stretch? Max Power <debian@cpnetserver.net> - 2018-01-02 12:50 +0100
    Re: Is there a way to know the ISP with the default installation of  Stretch? <tomas@tuxteam.de> - 2018-01-02 13:00 +0100
      Re: Is there a way to know the ISP with the default installation of  Stretch? Curt <curty@free.fr> - 2018-01-02 14:10 +0100
        Re: Is there a way to know the ISP with the default installation of  Stretch? <tomas@tuxteam.de> - 2018-01-02 15:00 +0100
          Re: Is there a way to know the ISP with the default installation of  Stretch? Jonathan Dowland <jmtd@debian.org> - 2018-01-02 17:30 +0100
    Re: Is there a way to know the ISP with the default installation of  Stretch? Michael Stone <mstone@debian.org> - 2018-01-02 14:30 +0100
    Re: Is there a way to know the ISP with the default installation of  Stretch? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-02 17:20 +0100
      Re: Is there a way to know the ISP with the default installation of   Stretch? Dan Purgert <dan@djph.net> - 2018-01-02 18:40 +0100
      Re: Is there a way to know the ISP with the default installation of  Stretch? David Wright <deblis@lionunicorn.co.uk> - 2018-01-03 10:30 +0100
        Re: Is there a way to know the ISP with the default installation of   Stretch? Dan Purgert <dan@djph.net> - 2018-01-03 14:10 +0100
          Re: Is there a way to know the ISP with the default installation of Stretch? rhkramer@gmail.com - 2018-01-03 16:40 +0100
            Re: Is there a way to know the ISP with the default installation of  Stretch? Nicolas George <george@nsup.org> - 2018-01-03 17:00 +0100
            Re: Is there a way to know the ISP with the default installation of  Stretch? Michael Stone <mstone@debian.org> - 2018-01-03 19:50 +0100
              Re: Is there a way to know the ISP with the default installation of  Stretch? David Wright <deblis@lionunicorn.co.uk> - 2018-01-04 02:10 +0100
                Re: Is there a way to know the ISP with the default installation of  Stretch? Michael Stone <mstone@debian.org> - 2018-01-04 05:40 +0100
                  Re: Is there a way to know the ISP with the default installation of  Stretch? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-07 14:40 +0100
              Re: Is there a way to know the ISP with the default installation of Stretch? rhkramer@gmail.com - 2018-01-04 02:30 +0100
        Re: Is there a way to know the ISP with the default installation of  Stretch? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-03 21:00 +0100
    Re: Is there a way to know the ISP with the default installation of   Stretch? Dan Purgert <dan@djph.net> - 2018-01-02 17:20 +0100
      Re: Is there a way to know the ISP with the default installation of  Stretch? <tomas@tuxteam.de> - 2018-01-03 09:20 +0100
        Re: Is there a way to know the ISP with the default installation of   Stretch? Dan Purgert <dan@djph.net> - 2018-01-03 13:10 +0100

Page 1 of 2  [1] 2  Next page →

#190533 — Is there a way to know the ISP with the default installation of Stretch?

My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
before starting browsing or any remote connection...
With the 'route' command it was so easy '# route' and goal!
With le last release 'Stretch' the net-tools packet is not installed by default.
But if this command was so useful, why It was removed?
I repeat, I need to know the ISP before to establish any connection!!
[I need this because some Italian provider, and are so many, do not allow
some services that machines provided... e.g.: VoIP, so I need to know the ISP 
before so to avoid initializing the machine.]
How Can I do with the default installation?

Thank for reply.

[toc] | [next] | [standalone]

#190534

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 02, 2018 at 12:42:35PM +0100, Max Power wrote:
> My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
> before starting browsing or any remote connection...
> With the 'route' command it was so easy '# route' and goal!
> With le last release 'Stretch' the net-tools packet is not installed by default.

There *just* was a thread around here: either use ip -r route (-r means
try to resolve IP address to name, your old "route" did exactly that),
or just install net-tools (as you said above).

> But if this command was so useful, why It was removed?

Folks, don't get so worked up when your favourite package is not
installed by default. Otherwise the default install would end up
installing *all* packages! Just go install it. If enough of you
do (and enable popcon, hint, hint) it might become again default,
who knows?

Whining here won't help and just makes the mailing list more
annoying.

FWIW, I have net-tools installed and use old and new. Happy camper.

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

iEYEARECAAYFAlpLc6IACgkQBcgs9XrR2kbIHQCdEDMOHSBs74jxEgUzAaAuddSp
Z9IAn1xlBdc+5M7UKkhKgdWNiYkWQB8K
=RJej
-----END PGP SIGNATURE-----

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

#190536

On 2018-01-02, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> On Tue, Jan 02, 2018 at 12:42:35PM +0100, Max Power wrote:
>> My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
>> before starting browsing or any remote connection...
>> With the 'route' command it was so easy '# route' and goal!
>> With le last release 'Stretch' the net-tools packet is not installed by default.
>
> There *just* was a thread around here: either use ip -r route (-r means
> try to resolve IP address to name, your old "route" did exactly that),
> or just install net-tools (as you said above).
>

There just was another thread around here initiated by Max Power, the
current OP, I do believe; not liking the answer(s) there or unsatisfied
with it(them) for some reason he decided to restart and rephrase (and
elucidate and expand in the tradition of obviating the XY problem,
though in this case his present Y problem seems to call for the same
response as his X did--or vice-versa).


-- 
"An autobiography is only to be trusted when it reveals something disgraceful.
A man who gives a good account of himself is probably lying, since any life
when viewed from the inside is simply a series of defeats."
— George Orwell

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

#190538

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 02, 2018 at 01:05:58PM +0000, Curt wrote:

[...]

> There just was another thread around here initiated by Max Power, the
> current OP, I do believe [...]

Indeed, it was Max (cc'ing him/her just in case). I didn't remember, but
checked now.

Hi, Max. I don't know what your intentions are in repeating your
qualms after two solutions were offered to you. Either get along
with the new "ip" or just install the old net-tools. They are not
going away (at least not as long as there are people maintaining
them, hint, hint).

It won't work always (e.g. if your provider doesn't... provide
reverse IP lookup *neither* ip -r *nor* route from net-tools
will do what you want!).

Debian can't declare *every* package as essential: I hope you
understand that.

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

iEYEARECAAYFAlpLjXsACgkQBcgs9XrR2kbXAgCaAuYoyMJ+fCh7aLGTiPPr2D4S
cesAoIJFqv+yRWd7gUYh+fvWHFuovT1N
=A943
-----END PGP SIGNATURE-----

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

#190549

On Tue, Jan 02, 2018 at 02:47:39PM +0100, tomas@tuxteam.de wrote:
>Hi, Max. I don't know what your intentions are in repeating your
>qualms after two solutions were offered to you. Either get along
>with the new "ip" or just install the old net-tools. They are not
>going away (at least not as long as there are people maintaining
>them, hint, hint).

As someone who dislikes ip(8), I suspect the eventual solution will be
a new, third tool. In the meantime I indeed just install net-tools and
get on with my life.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

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

#190537

On Tue, Jan 02, 2018 at 12:42:35PM +0100, Max Power wrote:
>My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
>before starting browsing or any remote connection...
>With the 'route' command it was so easy '# route' and goal!
>With le last release 'Stretch' the net-tools packet is not installed by default.
>But if this command was so useful, why It was removed?
>I repeat, I need to know the ISP before to establish any connection!!
>[I need this because some Italian provider, and are so many, do not allow
>some services that machines provided... e.g.: VoIP, so I need to know the ISP
>before so to avoid initializing the machine.]
>How Can I do with the default installation?

There isn't an easy way to do that, and there wasn't before. If 
resolving a non-routable IP happened to work for you previously that was 
just luck, not something to rely on. The most reliable method would be 
to use something like https://www.whatismyip.com/ that tells you the 
public IP you are using to make a connection.

Mike Stone

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

#190547

On Tue, Jan 02, 2018 at 04:03:46PM -0000, Dan Purgert wrote:
> Max Power wrote:
> > My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
> > before starting browsing or any remote connection...
> 
> Checking the hostname of an RFC1918 address will nearly never provide
> you with an ISP's name, even if you do it on a residential-gateway
> device provided by them.

I think the issue here is that he has some sort of unique setup in
which this name resolution actually DOES provide meaningful information,
much to the surprise of everyone else on the mailing list.

Unfortunately, he doesn't realize that this is atypical, so he doesn't
know enough to report it to us as part of his question.

Also unfortunately, we don't know what he's actually DOING with this
name resolution information, so we can't help him.

Most particularly, we don't know what the various ISP choices are that
he has, what the gateways of those ISPs are, what the name resolutions
of those gateways of those ISPs are, or what he wants to do in each of
the known, possible cases that he may encounter.

THAT is the kind of information we would need in order to help him.

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

#190552 — Re: Is there a way to know the ISP with the default installation of Stretch?

Greg Wooledge wrote:
> On Tue, Jan 02, 2018 at 04:03:46PM -0000, Dan Purgert wrote:
>> Max Power wrote:
>> > My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
>> > before starting browsing or any remote connection...
>> 
>> Checking the hostname of an RFC1918 address will nearly never provide
>> you with an ISP's name, even if you do it on a residential-gateway
>> device provided by them.
>
> I think the issue here is that he has some sort of unique setup in
> which this name resolution actually DOES provide meaningful information,
> much to the surprise of everyone else on the mailing list.

That's kind of why I was spelling it out in simple terms -- hadn't seen
anyone do that yet (or I missed it).  Sometimes ends up being the kick
people need for their ah-hah moment.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

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

#190592

On Tue 02 Jan 2018 at 11:15:16 (-0500), Greg Wooledge wrote:
> On Tue, Jan 02, 2018 at 04:03:46PM -0000, Dan Purgert wrote:
> > Max Power wrote:
> > > My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
> > > before starting browsing or any remote connection...
> > 
> > Checking the hostname of an RFC1918 address will nearly never provide
> > you with an ISP's name, even if you do it on a residential-gateway
> > device provided by them.
> 
> I think the issue here is that he has some sort of unique setup in
> which this name resolution actually DOES provide meaningful information,
> much to the surprise of everyone else on the mailing list.
> 
> Unfortunately, he doesn't realize that this is atypical, so he doesn't
> know enough to report it to us as part of his question.
> 
> Also unfortunately, we don't know what he's actually DOING with this
> name resolution information, so we can't help him.
> 
> Most particularly, we don't know what the various ISP choices are that
> he has, what the gateways of those ISPs are, what the name resolutions
> of those gateways of those ISPs are, or what he wants to do in each of
> the known, possible cases that he may encounter.
> 
> THAT is the kind of information we would need in order to help him.

I can only assume that the OP connects through a number of different
networks which have been set up with, perhaps, different ranges of
IP addresses. For example, and sticking to unroutable addresses, they
might be on 192.168.… in one place, 10.… in another etc.

I have no idea how you'd find out which ISP is being used, except by
making assumptions of this sort, without any connection (assuming
"external" connection). The only sugestion I can give to the OP
would be to use traceroute (if that wasn't blocked too):

$ traceroute -m 4 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 4 hops max, 60 byte packets
 1  router (192.168.1.1)  0.958 ms  2.627 ms  6.284 ms
 2  10.37.37.1 (10.37.37.1)  45.585 ms  45.544 ms  45.594 ms
 3  123.456.789.123 (123.456.789.123)  290.450 ms  290.493 ms  291.698 ms
 4  123.456.798.213 (123.456.798.213)  291.702 ms  291.634 ms  291.832 ms
$ 

In my own case, whois on either of the (garbled) addresses above
gives the correct ISP, Cox in Atlanta. Had the question been posed
a week earlier, I could have tried this from various establishments
across four more states.

Cheers,
David.

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

#190597 — Re: Is there a way to know the ISP with the default installation of Stretch?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Wright wrote:
> On Tue 02 Jan 2018 at 11:15:16 (-0500), Greg Wooledge wrote:
>> On Tue, Jan 02, 2018 at 04:03:46PM -0000, Dan Purgert wrote:
>> > Max Power wrote:
>> > > My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
>> > > before starting browsing or any remote connection...
>> > 
>> > Checking the hostname of an RFC1918 address will nearly never provide
>> > you with an ISP's name, even if you do it on a residential-gateway
>> > device provided by them.
>> 
>> I think the issue here is that he has some sort of unique setup in
>> which this name resolution actually DOES provide meaningful information,
>> much to the surprise of everyone else on the mailing list.
>> 
>> Unfortunately, he doesn't realize that this is atypical, so he doesn't
>> know enough to report it to us as part of his question.
>> 
>> Also unfortunately, we don't know what he's actually DOING with this
>> name resolution information, so we can't help him.
>> 
>> Most particularly, we don't know what the various ISP choices are that
>> he has, what the gateways of those ISPs are, what the name resolutions
>> of those gateways of those ISPs are, or what he wants to do in each of
>> the known, possible cases that he may encounter.
>> 
>> THAT is the kind of information we would need in order to help him.
>
> I can only assume that the OP [...]

That's the point :) that's all any of us can do. 

At the moment, he's already been told how to get "ip" to resolve
hostnames (in his other thread -- "ip -r route"), seems he didn't like
that answer; and made a new one.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaTNI/AAoJEI4R3fMSeaKBny0IAJc5WMppuzfz84P1n+p83SRY
HrgPbe+WFT1pldTJ6LJ8tI05vfXS/qGwYn2HXHBZ8ow8fNB34wTHQa4kMOcBqv2q
XKS8G6vsm2708CvK/Ho33E8FUgRadjW1W6D0qQRq/sdaOhFMJl3Grtxyb/pPSZGe
U8nkY/fIm925B22UI/DNmh8nDevtP50nZKLJd8QC86JpNOjIsT1BFUqCA/h6E+2z
WDU1fUxkvjqJ1P9kLhgcwNKhHSqa/VEw2dvusbJFnaLKkRtqryP0iURPNh2MX1ay
YnevBbvlyqsnpirQUiVXaJZUPK+90mfIzs61YIRbHMXG6bbK0rrePVn9kxCeOTw=
=NXZv
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

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

#190601 — Re: Is there a way to know the ISP with the default installation of Stretch?

On Wednesday, January 03, 2018 07:54:06 AM Dan Purgert wrote:
> At the moment, he's already been told how to get "ip" to resolve
> hostnames (in his other thread -- "ip -r route"), seems he didn't like
> that answer; and made a new one.

I hope the OP is still "listening".  (And I'm not the OP.)

(Extraneous Aside: I think it is strange that "we" talk about the OP instead 
of talking to him.)

Anyway, to the OP (and all):

It seems to me (without knowing the OPs complete problem, and based on what 
I've read in this thread) that traceroute may provide a way forward:

   * Connect to (any of) your ISP(s).

   * traceroute somewhere (I'm not sure where atm--maybe some neutral party 
like google)

   * Parse the results of the ping to get the numeric address of your ISP

   * whois that numeric address

I think that would give you the ISP's name.

Presumably this could be scripted, though I'm not sure how easily--I'm not 
sure either:

   * how to (consistently via script) determine which response to the 
traceroute is from your ISP, although I would guess it is the first non-private 
(non-RFC1918) address

   * how to (consistently via script) determine the ISP from the whois

This almost works for me--the problem for me is that my ISP is Earthlink which 
uses / shares the Verizon network, so I find references to Verizon in the whois 
results, but not Earthlink.

PS: I tried to also send this to the OP (Max Power) (because I don't know if 
he is subscribed to the list) , but I'm not sure I have a valid email address.

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

#190604

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

rhkramer@gmail.com (2018-01-03):
> I hope the OP is still "listening".

If he is, he is probably enjoying the time wasted by his nonsensical
question.

Regards,

-- 
  Nicolas George

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

#190617

On Wed, Jan 03, 2018 at 10:36:32AM -0500, rhkramer@gmail.com wrote:
>I've read in this thread) that traceroute may provide a way forward:

In general, no. Many ISPs use RFC1918 space internally, so you need to 
skip an unknown number of hops before you get to a routeable IP, at 
which point you may or may not find an address that's assigned to the 
entity providing your internet access (as opposed to whoever is 
providing their internet access).

Mike Stone

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

#190638

On Wed 03 Jan 2018 at 13:39:14 (-0500), Michael Stone wrote:
> On Wed, Jan 03, 2018 at 10:36:32AM -0500, rhkramer@gmail.com wrote:
> >I've read in this thread) that traceroute may provide a way forward:
> 
> In general, no. Many ISPs use RFC1918 space internally, so you need
> to skip an unknown number of hops before you get to a routeable IP,

(In view of
https://lists.debian.org/debian-user/2018/01/msg00126.html
do you mean public?)

> at which point you may or may not find an address that's assigned to
> the entity providing your internet access (as opposed to whoever is
> providing their internet access).

But in that case, would https://www.whatismyip.com/ reveal an address
closer to the OP than whoever is providing *their* internet access?
(IOW does https://www.whatismyip.com/ ever yield a private address?)

My idea of using traceroute (the example illustrated the private
address "problem") was not offered to provide a "solution" to
the problem, but only to suggest some means by which the OP
might decide whether to try using a particular service. But
I have no idea why the OP doesn't just try the service to see
whether it is supported, rather than playing guessing games
in advance. And as I posted earlier, I have no idea where the
OP obtained the string home.telecomitalia.it from, and they
haven't yet told us.

Cheers,
David.

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

#190642

On Wed, Jan 03, 2018 at 07:04:46PM -0600, David Wright wrote:
>(In view of
>https://lists.debian.org/debian-user/2018/01/msg00126.html
>do you mean public?)

No, it's a pretty common shorthand to say "routable" to mean "routable 
on the public internet", especially where there's no real possibility of 
confusing it with specifically non-routable blocks like 127.0.0.0/8.  
Honestly, I considered it less likely to be confusing than calling them 
RFC1918 addresses in this context. 

As far as 169.254.0.0/16, it's defined as a link local range for address 
autoconfiguration, but it can still be routed internally just as much as 
the RFC1918 space can be. (Doing so just might not be a good idea, 
because some devices might code in some assumptions or add a zeroconf 
route by default. Which is annoying because the whole automatic zero 
knowledge IPv4 autoconfiguration thing is just a spectacularly bad idea 
anyway that typically causes far more trouble than it's worth. I guess 
it was useful back in the days when someone might want to connect two 
win98 machines together to copy a file without using a floppy disk but 
couldn't think of a reason they might want to use the internet.) IPv6 
has an entirely different (and more useful) concept of link local 
addresses. Some of the other reserved ranges can also be internally 
routed in practice, so trying to distinguish between "routable" and 
"non routable" for some meaning other than "not routable on the public 
internet" rapidly becomes a game of semantics and implementations.

>But in that case, would https://www.whatismyip.com/ reveal an address
>closer to the OP than whoever is providing *their* internet access?
>(IOW does https://www.whatismyip.com/ ever yield a private address?)

No, it can't. It will show a public IP that connections from the web 
client to connect to that particular web site, not a private IP. In the 
case of a NAT environment there may be multiple different IPs in use, or 
there may be different IPs for different routes, but there's no reliable 
way to enumerate every possible IP you might be NATed to.

Back to the traceroute idea: it's fairly common for a residential 
endpoint to have a publically routable IP (usually on the router or 
"modem") but traceroute won't help identify that--instead, you'll see 
the private IP that the modem uses to communicate with the machine 
running traceroute.  (In general, traceroute will only show one of many 
IPs that a particular hop has.) So what you're getting from traceroute 
isn't going to be the IP you use when communicating with web sites, it's 
going to be the IP your router uses to communicate with you, then IPs 
associated with other routers along the way (some of which may also be 
using RFC1918 space, though it's more common these days for large 
providers to just pass around encapsulated traffic in a way that's 
opaque to traceroute, likely over IPv6). In theory another option for 
finding the public-side gateway IP is UPnP IGD or PCP, but I wouldn't 
expect those to work on any arbitrary network.

Mike Stone

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

#190745

Le 04/01/2018 à 05:32, Michael Stone a écrit :
> 
> No, it's a pretty common shorthand to say "routable" to mean "routable 
> on the public internet", especially where there's no real possibility of 
> confusing it with specifically non-routable blocks like 127.0.0.0/8. 

This is still a mistake. In technical fields such as this one, words 
have a well defined meaning.

> Honestly, I considered it less likely to be confusing than calling them 
> RFC1918 addresses in this context.

What about "private", as defined in RFC1918 ?

> As far as 169.254.0.0/16, it's defined as a link local range for address 
> autoconfiguration, but it can still be routed internally just as much as 
> the RFC1918 space can be.

No, unless you're ready to violate the standards. RFC3927 (Dynamic 
Configuration of IPv4 Link-Local Addresses) explicitly states in chapter 
7 "Router Considerations" :

    A router MUST NOT forward a packet with an IPv4 Link-Local source or
    destination address, irrespective of the router's default route
    configuration or routes obtained from dynamic routing protocols.

    A router which receives a packet with an IPv4 Link-Local source or
    destination address MUST NOT forward the packet.  This prevents
    forwarding of packets back onto the network segment from which they
    originated, or to any other segment.

Note that it says "MUST", not "SHOULD".

> (Doing so just might not be a good idea, 

Yes, violating the standards is often a bad idea.

> because some devices might code in some assumptions

What you call "assumptions" is just compliance with the standards.

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

#190640 — Re: Is there a way to know the ISP with the default installation of Stretch?

On Wednesday, January 03, 2018 01:39:14 PM Michael Stone wrote:
> On Wed, Jan 03, 2018 at 10:36:32AM -0500, rhkramer@gmail.com wrote:
> >I've read in this thread) that traceroute may provide a way forward:
> In general, no. Many ISPs use RFC1918 space internally, so you need to
> skip an unknown number of hops before you get to a routeable IP, at
> which point you may or may not find an address that's assigned to the
> entity providing your internet access (as opposed to whoever is
> providing their internet access).

Ahh, ok, thanks!

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

#190621

Le 03/01/2018 à 03:19, David Wright a écrit :
> 
> For example, and sticking to unroutable addresses, they
> might be on 192.168.… in one place, 10.… in another etc.

Private addresses are routable. They are just not routed over the public 
internet. Link local addresses (169.254.0.0/16) are not routable.

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

#190548 — Re: Is there a way to know the ISP with the default installation of Stretch?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max Power wrote:
> My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
> before starting browsing or any remote connection...

Checking the hostname of an RFC1918 address will nearly never provide
you with an ISP's name, even if you do it on a residential-gateway
device provided by them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaS602AAoJEI4R3fMSeaKBWC8H/R8L0m81riHdFQ/c3xTKI68O
hMbjC4gAJ3uKbfcraAT8QakonR14R+acmFlN4hJW4bAmMDw4lsD+2uv3h2A6vxqR
cmn0SIszvcadMlsQSg+87GN4lgT09PpLqdUjSKEJ8aYlGjxqUR42IDv3cf0TjvVa
kaH+sNdfz+CyOuknMzUpJORVSCNip0NNaTPIAchvjcLr2BtDHMyGAbwHrT9QEYQk
nr9wCJzyXS5eeig/S4iiMvn9NGcx3TIw+UApwDf74tgD7Hhv5uva9P/8IlPCb/sE
36AH9IGPQKHjt4Ooyi/BOXO9oc0AbUALbMUHudjc7lko4ygrhe10df04N2+oZYo=
=rF/8
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

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

#190589

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 02, 2018 at 04:03:46PM -0000, Dan Purgert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Max Power wrote:
> > My problem is to know the ISP [e.g. GATEWAY = Vodafone, Telecom or AT&T]
> > before starting browsing or any remote connection...
> 
> Checking the hostname of an RFC1918 address will nearly never provide
> you with an ISP's name, even if you do it on a residential-gateway
> device provided by them.

I think the OP's address was the external address, which very probably
*isn't* an RFC1918 (unless his provider puts all of their customers
behind a giant NAT: at least on my part of the world this is highly
atypical).

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpMkIgACgkQBcgs9XrR2kaYfwCaA2ceXxFjm2efv6hR25DBYu60
hz0An2YCF5YDOeSY9fZ4duxQ97w57ESJ
=WCgo
-----END PGP SIGNATURE-----

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web