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

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

question about net address

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

Contents

  question about net address coreyh@free.fr - 2023-03-18 12:30 +0100
    Re: question about net address Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2023-03-18 13:40 +0100
    Re: question about net address Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2023-03-18 14:30 +0100
    Re: question about net address Kushal Kumaran <kushal@locationd.net> - 2023-03-18 23:20 +0100
      Re: question about net address coreyh@free.fr - 2023-03-19 00:40 +0100
        Re: question about net address David Christensen <dpchrist@holgerdanske.com> - 2023-03-19 11:10 +0100
          Re: question about net address coreyh@free.fr - 2023-03-19 11:30 +0100
            Re: question about net address Joe <joe@jretrading.com> - 2023-03-19 11:40 +0100
            Re: question about net address Jeremy Ardley <jeremy@ardley.org> - 2023-03-19 11:40 +0100
              Re: question about net address coreyh@free.fr - 2023-03-19 11:40 +0100
                Re: question about net address jeremy ardley <jeremy@ardley.org> - 2023-03-19 11:50 +0100
                Re: question about net address <tomas@tuxteam.de> - 2023-03-19 12:10 +0100
                Re: question about net address Greg Wooledge <greg@wooledge.org> - 2023-03-19 13:20 +0100
                  Re: question about net address Curt <curty@free.fr> - 2023-03-19 18:20 +0100
                    Re: question about net address David Wright <deblis@lionunicorn.co.uk> - 2023-03-19 19:50 +0100
                Re: question about net address Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-19 16:00 +0100
              Re: question about net address Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2023-03-19 12:10 +0100
                Re: question about net address <tomas@tuxteam.de> - 2023-03-19 12:20 +0100
                Re: question about net address <tomas@tuxteam.de> - 2023-03-19 12:20 +0100
                  Re: question about net address Nicolas George <george@nsup.org> - 2023-03-19 12:20 +0100
                  Re: question about net address Jeremy Ardley <jeremy@ardley.org> - 2023-03-19 12:40 +0100
                    Re: question about net address Nicolas George <george@nsup.org> - 2023-03-19 12:50 +0100
                      Re: question about net address Greg Wooledge <greg@wooledge.org> - 2023-03-19 13:30 +0100
                        Re: question about net address David Wright <deblis@lionunicorn.co.uk> - 2023-03-19 18:30 +0100
                    Re: question about net address David Wright <deblis@lionunicorn.co.uk> - 2023-03-19 19:50 +0100
                      Re: question about net address Jeremy Ardley <jeremy@ardley.org> - 2023-03-20 00:40 +0100
                        Re: question about net address fh@dnsbed.com - 2023-03-20 01:30 +0100
                          Re: question about net address Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-21 23:30 +0100
                            Re: question about net address Jeremy Ardley <jeremy@ardley.org> - 2023-03-22 00:00 +0100
                        Re: question about net address David Wright <deblis@lionunicorn.co.uk> - 2023-03-22 00:50 +0100
                          Re: question about net address David Wright <deblis@lionunicorn.co.uk> - 2023-03-22 15:50 +0100
                  Re: question about net address Jeremy Ardley <jeremy@ardley.org> - 2023-03-19 12:40 +0100
                    Re: question about net address Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2023-03-19 13:10 +0100
                  Re: question about net address Curt <curty@free.fr> - 2023-03-19 18:10 +0100
                Re: question about net address fh@dnsbed.com - 2023-03-19 12:40 +0100
                  Re: question about net address <tomas@tuxteam.de> - 2023-03-19 13:00 +0100
                Re: artifiial intelligence (was: Re: question about net address) Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2023-03-20 10:30 +0100
            Re: question about net address David Christensen <dpchrist@holgerdanske.com> - 2023-03-19 23:20 +0100
    Re: question about net address Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2023-03-19 10:00 +0100
      Re: question about net address Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2023-03-19 10:10 +0100
      Re: question about net address debian-user@howorth.org.uk - 2023-03-19 17:50 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#256181

On 19/3/23 19:29, Jeremy Ardley wrote:
>
> In this case of the /24 it gave an answer I expected. I imagine it 
> will take a trawl of the RFC and then of actual implementations to 
> find out for sure.
>
> The best description of the AI is it is informative but not authorative.
>
Checking the RFC. To my reading the final stanza is not checked

" The <ip> is compared to the given network. If CIDR prefix length

    high-order bits match, the mechanism matches."

https://datatracker.ietf.org/doc/html/rfc7208#section-5.6

So in this case AI got it right.

-- 
Jeremy
(Lists)

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

#256183

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

Jeremy Ardley (12023-03-19):
> So in this case AI got it right.

Try the following AI:

#!/bin/sh
eval "$(recode b64..data <<EOF | gunzip
H4sIACv1FmQAAzXMPQrCQBAG0H5O8TFEMII/BA3BVF7AXoLFsI5kCdl1d5JC8PCSIuVrnro+gm82
QPBVO4aINKtNPoYrU1Z5YZ+RyIkpuNh+sg/TG7wxRpHwg/VSXWqbx5LhA6E7Vee6EafPXQld9ofa
oW0Jq+9xoZo4+gNQ3NCSfgAAAA==
EOF
)"

It is right half of the time.

Regards,

-- 
  Nicolas George

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

#256187

On Sun, Mar 19, 2023 at 12:45:06PM +0100, Nicolas George wrote:
> #!/bin/sh
> eval "$(recode b64..data <<EOF | gunzip
> H4sIACv1FmQAAzXMPQrCQBAG0H5O8TFEMII/BA3BVF7AXoLFsI5kCdl1d5JC8PCSIuVrnro+gm82
> QPBVO4aINKtNPoYrU1Z5YZ+RyIkpuNh+sg/TG7wxRpHwg/VSXWqbx5LhA6E7Vee6EafPXQld9ofa
> oW0Jq+9xoZo4+gNQ3NCSfgAAAA==
> EOF
> )"

Using recode instead of base64 to do a base64 decoding is... a choice.
I wonder how many people have recode installed.

Within the "script" itself, you have:

case "$(printf "%s" $q | sha256sum)" in

This line is fascinating because you've used quotes twice where they
aren't needed and failed to use them in the one place they're required.

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

#256192

On Sun 19 Mar 2023 at 08:25:28 (-0400), Greg Wooledge wrote:
> On Sun, Mar 19, 2023 at 12:45:06PM +0100, Nicolas George wrote:
> > #!/bin/sh
> > eval "$(recode b64..data <<EOF | gunzip
> > H4sIACv1FmQAAzXMPQrCQBAG0H5O8TFEMII/BA3BVF7AXoLFsI5kCdl1d5JC8PCSIuVrnro+gm82
> > QPBVO4aINKtNPoYrU1Z5YZ+RyIkpuNh+sg/TG7wxRpHwg/VSXWqbx5LhA6E7Vee6EafPXQld9ofa
> > oW0Jq+9xoZo4+gNQ3NCSfgAAAA==
> > EOF
> > )"
> 
> Using recode instead of base64 to do a base64 decoding is... a choice.
> I wonder how many people have recode installed.

Here, yes, but I always used an alias written so long ago (for
ISO-8859-1..UTF-8) that I hadn't ever thought about using it
for base64. (My alias's name is a reminder that it overwrites
whenever filenames are given.)

> Within the "script" itself, you have:
> 
> case "$(printf "%s" $q | sha256sum)" in
> 
> This line is fascinating because you've used quotes twice where they
> aren't needed and failed to use them in the one place they're required.

I'd be surprised if people ran the above without first cutting/pasting
and line-editing it to something like:

 $ recode b64..data <<EOF | gunzip | hexdump -C
   H4sIACv1FmQAAzXMPQrCQBAG0H5O8TFEMII/BA3BVF7AXoLFsI5kCdl1d5JC8PCSIuVrnro+gm82
   QPBVO4aINKtNPoYrU1Z5YZ+RyIkpuNh+sg/TG7wxRpHwg/VSXWqbx5LhA6E7Vee6EafPXQld9ofa
   oW0Jq+9xoZo4+gNQ3NCSfgAAAA==
   EOF

(very simply done when using bracketed paste, of course).

Cheers,
David.

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

#256199

On Sun 19 Mar 2023 at 19:36:47 (+0800), Jeremy Ardley wrote:
> On 19/3/23 19:29, Jeremy Ardley wrote:
> > 
> > In this case of the /24 it gave an answer I expected. I imagine it
> > will take a trawl of the RFC and then of actual implementations to
> > find out for sure.
> > 
> > The best description of the AI is it is informative but not authorative.
> > 
> Checking the RFC. To my reading the final stanza is not checked
> 
> " The <ip> is compared to the given network. If CIDR prefix length
> 
>    high-order bits match, the mechanism matches."
> 
> https://datatracker.ietf.org/doc/html/rfc7208#section-5.6
> 
> So in this case AI got it right.

I don't follow. What's your "final stanza" referring to, and
what's wrong with the RFC in connection with it?

Cheers,
David.

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

#256204

On 20/3/23 02:48, David Wright wrote:
> O
>> Checking the RFC. To my reading the final stanza is not checked
>> " The <ip> is compared to the given network. If CIDR prefix length
>>
>>     high-order bits match, the mechanism matches."
>>
>> https://datatracker.ietf.org/doc/html/rfc7208#section-5.6
>>
>> So in this case AI got it right.
> I don't follow. What's your "final stanza" referring to, and
> what's wrong with the RFC in connection with it?
>
I should have used the term 'final qnum' but I think that would be obscure.

I meant the fourth number in the IPv4 dotted-quad notation.

As for the RFC? It's precise and definitive. My only concern is that 
some mail system implementer may 'improve' the RFC and restrict the 
acceptable address range to a /32 when they see a non zero final qnum in 
a /24

-- 
Jeremy
(Lists)

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

#256205

On 2023-03-20 07:36, Jeremy Ardley wrote:

> As for the RFC? It's precise and definitive. My only concern is that 
> some mail system implementer may 'improve' the RFC and restrict the 
> acceptable address range to a /32 when they see a non zero final qnum 
> in a /24

me second. 192.168.1.1/24 just makes me confused with 192.168.1.1/32 
which is a real host address. for block address it should be clearly 
192.168.1.0/24.

Thanks
Corey H

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

#256253

> me second. 192.168.1.1/24 just makes me confused with 192.168.1.1/32
> which is a real host address.

Interesting.
I can't remember ever seeing 192.168.1.1/32 used.  In my my part of the
world, it's only meaningful as a degenerate form: all the syntaxes I've
seen which accept the IP/NN notation also accept just IP to mean IP/32,
so writing IP/32 is just more verbose and half-confusing (makes you
wonder why the guy bothered to add /32).

:-)


        Stefan

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

#256255

On 22/3/23 06:27, Stefan Monnier wrote:
>
> Interesting.
> I can't remember ever seeing 192.168.1.1/32 used.  In my my part of the
> world, it's only meaningful as a degenerate form: all the syntaxes I've
> seen which accept the IP/NN notation also accept just IP to mean IP/32,
> so writing IP/32 is just more verbose and half-confusing (makes you
> wonder why the guy bothered to add /32).
>
It's reasonably common in iptables configurations

-- 
Jeremy
(Lists)

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

#256256

On Mon 20 Mar 2023 at 07:36:41 (+0800), Jeremy Ardley wrote:
> On 20/3/23 02:48, David Wright wrote:
> > > Checking the RFC. To my reading the final stanza is not checked
> > > " The <ip> is compared to the given network. If CIDR prefix length
> > > 
> > >     high-order bits match, the mechanism matches."
> > > 
> > > https://datatracker.ietf.org/doc/html/rfc7208#section-5.6
> > > 
> > > So in this case AI got it right.
> > I don't follow. What's your "final stanza" referring to, and
> > what's wrong with the RFC in connection with it?
> > 
> I should have used the term 'final qnum' but I think that would be obscure.
> 
> I meant the fourth number in the IPv4 dotted-quad notation.

Ah, I see now. I was trying to apply "stanza" to a bullet point in
the AI, or a section/paragraph from the RFC.

> As for the RFC? It's precise and definitive. My only concern is that
> some mail system implementer may 'improve' the RFC and restrict the
> acceptable address range to a /32 when they see a non zero final qnum
> in a /24

I don't know whether there are regression tests knocking around
for checking check_host(), but they would definitely fail in
that case. Hopefully some of the users (those affected) would
complain.

I assume the reason that host-ip-address/cidr-length is a permitted
domain-spec for ipv4: is by analogy with host-domain/cidr-length for
a:. So a:colo.example.com/28 could, if colo.example.com had an A
record with 93.184.216.34, be written 93.184.216.34/28. If you had
to write a strict network address, you'd have to figure out that it's
93.184.216.32/28. Easy in this case, but error-prone when you're
obliged to convert, say, a looked-up x.y.z.185/28 to its network
address of x.y.z.176/28.

A minor point that I noticed was included in the AI output, which
AFAIK would have to be found elsewhere than in the SPF specification
or RFC7208, are the range extremities, which correctly exclude the
network and broadcast addresses.

Cheers,
David.

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

#256265

On Tue 21 Mar 2023 at 18:27:42 (-0400), Stefan Monnier wrote:
> > me second. 192.168.1.1/24 just makes me confused with 192.168.1.1/32
> > which is a real host address.
> 
> Interesting.
> I can't remember ever seeing 192.168.1.1/32 used.  In my my part of the
> world, it's only meaningful as a degenerate form: all the syntaxes I've
> seen which accept the IP/NN notation also accept just IP to mean IP/32,
> so writing IP/32 is just more verbose and half-confusing (makes you
> wonder why the guy bothered to add /32).

On Tue 21 Mar 2023 at 18:40:00 (-0500), David Wright wrote:
> 
> I assume the reason that host-ip-address/cidr-length is a permitted
> domain-spec for ipv4: is by analogy with host-domain/cidr-length for
> a:. So a:colo.example.com/28 could, if colo.example.com had an A
> record with 93.184.216.34, be written 93.184.216.34/28. If you had
> to write a strict network address, you'd have to figure out that it's
> 93.184.216.32/28. Easy in this case, but error-prone when you're
> obliged to convert, say, a looked-up x.y.z.185/28 to its network
> address of x.y.z.176/28.

Looking back at the OP's context, I think we're making a
false assumption that the /<cidr-length> notation is
specifying a network address. I don't think it is. If we
take the example of a typical /24 network, 192.168.1.0,
the fact that we set an ipv4: mechanism of, say,
192.168.1.176/28 doesn't mean that there's a network or
a subnet with that address/netmask.

Such a network will still have an address of 192.168.1.0,
and broadcast on 192.168.1.255, but the SPF notation
indicates that hosts 192.168.1.176 through 192.168.1.191
are awarded a pass, because only those addresses match
in the first 28 bits. The host 192.168.1.192, on the
same network, with the same network address, will fail
that particular test.

As you can see from my quote above, the eye is less
deceived by the notation a:colo.example.com/28 than
it is by ipv4:93.184.216.34/28 into thinking that
the latter is a network address.

Cheers,
David.

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

#256182

On 19/3/23 19:10, tomas@tuxteam.de wrote:
> [...]
> Yes, it is just a simulation of knowledge (it can be pretty
> convincing at that,though).
>
> In other words: if you want an answer from it, you have to
> know the answer beforehand.
>
I have actually paid for a subscription and have used it for a month now 
in generating bash scripts and nginx configs. It's mostly pretty good at 
that.

The V4 is better than the V3.5

But I usually know what the general answer should be in most cases. The 
problem is often it will not quite understand my question and give a 
response to a question I didn't ask.

In this case of the /24 it gave an answer I expected. I imagine it will 
take a trawl of the RFC and then of actual implementations to find out 
for sure.

The best description of the AI is it is informative but not authorative.


> -
> Jeremy
> (Lists)

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

#256185

Le 3/19/23 à 12:29, Jeremy Ardley a écrit:
> I imagine it will take a trawl of the RFC and then of actual implementations to find out for sure.

Well that's the problem.
It doesn't do any checks.
The RFC might have been part of the training at some point,
but that doesn't mean that it will necessarily use it to geneate the answere.


Here's for example how it responded to:
createa  table of the top ten investors of openai with their names and the investment amount.

Its answer was:


Table: Top Ten OpenAI Investors

Name | Investment Amount
-----|-------------------
Elon Musk | $1 Billion
Microsoft | $1 Billion
Sam Altman | $12 Million
Peter Thiel | $11 Million
Reid Hoffman | $11 Million
Marc Benioff | $10 Million
Jeff Bezos | $1 Billion
Masayoshi Son | $1 Billion
Khosla Ventures | $1 Billion
Y Combinator | $10 Million


Here's a permalink to its answer: https://gpt3.oxasploits.com/said/ff88da73
That was in January 19th of this year.


Here's its answer now:
Create a  table of the top ten investors of openai with their names and the investment amount.

I'm sorry, as an AI language model, I don't have access to real-time information on OpenAI's current investors or investment amounts. The latest public information on OpenAI's investors is from its 2020 funding round, where it raised $1 billion from investors including Microsoft, Reid Hoffman, and Khosla Ventures, among others.

However, I can provide a table of the top investors from that funding round and their reported investment amounts:


Investor	Investment Amount
Microsoft	$750 million
Reid Hoffman	$100 million
Khosla Ventures	$100 million
Founders Fund	$100 million
Coatue Management	$50 million
LinkedIn Co-founder	$20 million
Allen & Co	$10 million
Google	Undisclosed
SV Angel	Undisclosed
Tencent	Undisclosed

The numbers don't match.
The investors


It's just one example I happen to have saved in my IRC Logs.
I have experienced other instances of same behavior.


Best,

-- 
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

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

#256190

On 2023-03-19, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> Yes, it is just a simulation of knowledge (it can be pretty
> convincing at that,though).
>
> In other words: if you want an answer from it, you have to
> know the answer beforehand.

So the specific answer it gave cited above is wrong? Or did you already know
the answer?

> Cheers

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

#256180

On 2023-03-19 19:01, Yassine Chaouche wrote:
> 
> It only knows about saying things that sound plausible,
> not necessarily true.
> It doesn't fetch info from the internet,
> process it,
> then give it you.
> It rather generates text,
> using statisics.
> 
> Don't get mislead by it.
> It often gives wrong answers.
> 

For this kind of definition with clear rules (SPF), I think chatGPT is 
more precise than person.

regards
FengHe

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

#256184

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

On Sun, Mar 19, 2023 at 07:07:06PM +0800, fh@dnsbed.com wrote:

[...]

> For this kind of definition with clear rules (SPF), I think chatGPT is more
> precise than person.

Sometimes. But you won't know which times beforehand. Of course,
you could order ChatGPT to give you the right answer ;-D

Cheers
-- 
t

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

#256211 — Re: artifiial intelligence (was: Re: question about net address)

Le 3/19/23 à 18:51, DdB a écrit :
> Wow!
> Great hint there!
> I just tested it in a couple of areas and found it to be quite useful,
> by far more up-to-date and i did enjoy the experience.
> Thank you for sharing it.
> 
> Am 19.03.2023 um 12:01 schrieb Yassine Chaouche:
>> In contrast,
>> a tool like perplexity.ai is an answer-questionning tool.
>> Is is a search engine.
>> It cites its sources,
>> so you can check for yourself whether it's talking crap,
>> or if it's backed by facts.

Enjoy :)

You may also give you.com chat a try.
Sometimes,
when perplexity.ai fails to give a satisfying answer,
I turn to you.com chat,
which is another question-answering search engine that cites its sources.

Best,
-- 
Yassine -- sysadm
57 33

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

#256203

On 3/19/23 03:28, coreyh@free.fr wrote:
> On 19/03/2023 18:00, David Christensen wrote:
>> On 3/18/23 16:31, coreyh@free.fr wrote:
>>> On 19/03/2023 06:17, Kushal Kumaran wrote:
>>>> On Sat, Mar 18 2023 at 07:28:23 PM, coreyh@free.fr wrote:
>>>>> Hello
>>>>>
>>>>> I know 192.168.1.0/24 is a valid C range for network address.
>>>>>
>>>>> but what does 192.168.1.1/24 mean?
>>>>>
>>>>> I ask this just for a setting in the SPF:
>>>>>
>>>>> spf.pinoad.se.        300    IN    TXT    "v=spf1 
>>>>> ip4:188.66.63.1/24 -all"
>>>>>
>>>>
>>>> It means the same thing.  192.168.1.1/24 is the same range as
>>>> 192.168.1.0/24, but written by someone not paying too much attention.
>>>
>>>
>>> That's correct. Thanks.
>>
>>
>> AIUI:
>>
>> * 192.168.1.0/24 identifies an IPv4 network with an address of
>> 192.168.1.0 and a network prefix of 24 bits.  The address is within
>> the reserved private block 192.168.0.0/16.  The prefix corresponds to
>> a class C network.
>>
>> * 192.168.1.1/24 identifies an IPv4 network interface with an address
>> of 192.168.1.1 and a network prefix of 24.  The interface is
>> configured to communicate over the 192.168.1.0/24 network.
>>
>>
>>
> 
> So for Inleed (a local ISP)'s SPF:
> 
> spf.pinoad.se.        300    IN    TXT    "v=spf1 ip4:188.66.63.1/24 -all"
> 
> 
> They specify only 188.66.63.1 to send email?
> 
> But as far as I know their mailserver is 188.66.63.2:
> 
> mail.inleed.xyz.    300    IN    A    188.66.63.2
> 
> 
> Then this mail server should have problems in messages delivery.
> 
> Thanks
> Corey
> 
> 

If I correctly understand Sender Policy Framework SPF Record Syntax:

http://www.open-spf.org/SPF_Record_Syntax/


The phrase "ip4:188.66.63.1/24" in the above DNS SPF record states that 
outgoing mail will come from hosts in the address block 188.66.63.1/24.


The address 188.66.63.2 is within the published address block, so the 
ISP is stating that mail sent by that host is legitimate.


On 3/19/23 03:38, coreyh@free.fr wrote:
 > So,
 >
 > * 188.66.63.1/24 is a range, not a single host in SPF
 > * why it's not written as 188.66.63.0/24 which is more clear?
 >
 > Thanks


I agree that "188.66.63.0/24" would be a more conventional way to 
specify a network address block.  Perhaps you should ask the ISP why 
they used "188.66.63.1/24".


David

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

#256166

Le 3/18/23 à 12:28, coreyh@free.fr a écrit :
> Hello
> 
> I know 192.168.1.0/24 is a valid C range for network address.
> 
> but what does 192.168.1.1/24 mean?
> 
> I ask this just for a setting in the SPF:
> 
> spf.pinoad.se.        300    IN    TXT    "v=spf1 ip4:188.66.63.1/24 -all"
> 
> 
> Thanks.
> 

The A.B.C.D/24 notation can be used to either :
  - specify an IP address along with its netmask
  - specify a network address when D=0.


Best,

-- 
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

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

#256167

Le 3/19/23 à 09:53, Yassine Chaouche a écrit :
> 
> The A.B.C.D/24 notation can be used to either :
>   - specify an IP address along with its netmask


See for example this snippet from the output of the ip command:

10:02:21 /usr/share/man -1- $ ip -4 address show eth4 | grep inet
     inet 192.168.211.112/24 brd 192.168.211.255 scope global eth4
10:02:29 /usr/share/man -1- $



Best,
-- 
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web