Re: iwd: Using iwd to connect to a wireless network (Part 1 - Connection status show OK but unable to surf the net)
On Wed, Sep 29, 2021 at 03:09:55PM -0400, Dan Ritter wrote:
> Stella Ashburne wrote:
> > [IPv4]
> > Address=192.168.1.10
> > Netmask=255.255.255.0
> > Gateway=192.168.1.1
> > Broadcast=192.168.1.255
> > DNS=192.168.1.1
> >
> > In the above example the broadcast IP is 192.168.1.255.
> >
> > Question: Does the fourth octet have to be 255?
>
> Technically, no. In practice, you are unlikely to see anything
> else unless you are configuring point-to-point router links.
A 32-bit IPv4 address actually consists of two pieces: a network
address, and a host address. The netmask determines where the separation
is between these two pieces.
A netmask address is always a contiguous set of "1" bits followed by a
contiguous set of "0" bits. There are 32 bits altogether. The only
thing that matters is how many "1" bits there are, which determines the
length of the network address piece.
Thus, in more modern notations, the netmask is often written as a simple
number with a slash before it. Your 255.255.255.0 netmask can also be
written as "/24", because it has 24 "1" bits and 8 "0" bits.
Here's how that works. "255" is a number written in base 10. But if
we write it in binary (base 2), it looks like this: 11111111
So, the binary representation of your netmask 255.255.255.0 is:
11111111 11111111 11111111 00000000
That's 24 "1" bits, and 8 "0" bits, written out in long form.
Now, why on earth do we care what it looks like in base 2? Because of
how it's used. The netmask is called a "mask" because it can be overlaid
on top of another number. It blocks out certain pieces, and lets other
pieces show through. This is done with bitwise arithmetic operations
("AND", "OR" and "NOT").
To see it in action, let's apply this netmask to your IPv4 address, which
in the example above is 192.168.1.10.
We write this address out in base 2:
11000000 10101000 00000001 00001010
Now write it out with the netmask right underneath it:
11000000 10101000 00000001 00001010 (192.168.1.10)
11111111 11111111 11111111 00000000 (255.255.255.0)
Now we use bitwise AND to get the network address piece. We look at each
column individually. If both values are "1", the result is "1". Otherwise,
the result is "0". This gives us:
11000000 10101000 00000001 00001010 (192.168.1.10)
11111111 11111111 11111111 00000000 (255.255.255.0)
11000000 10101000 00000001 00000000 (192.168.1.0)
And voila: the network address is 192.168.1.0.
The "mask" part works like this: all of the "1"s are like open space
in a physical mask. They let the underlying image come through. All of
the "0"s are opaque material. They hide whatever's underneath.
So, you're only seeing the piece of the underlying address that lines
up with the "1"s in the mask.
Now, you might be thinking: "Hey, I could have just chopped off the
last digit of the IPv4 address and replaced it with a 0! What's with
all this binary nonsense?!"
That assertion is correct for a /24 netmask only. It's a special case.
The bitwise arithmetic tells us how it works in general, with other
netmasks that aren't multiples of 8.
Finally, let's demonstrate how we get the host address piece. For this,
we invert ("NOT") the bits of the netmask, and then "AND" it with the
IPv4 address:
Inverting the netmask gives us:
00000000 00000000 00000000 11111111
Applying the inverted mask gives:
11000000 10101000 00000001 00001010 (192.168.1.10)
00000000 00000000 00000000 11111111 (0.0.0.255)
00000000 00000000 00000000 00001010 (0.0.0.10)
So, the host address part is 0.0.0.10. This identifies the unique
device on the network.
Once again, this looks overly complicated because we're dealing with a
special case, where the number of bits in the netmask is a multiple of 8.
In the general case, where the netmask could be something like /29, the
host address could be a part of a byte, and not easily spotted in the
base 10 "dotted quad" notation that we normally use.
It's also worth pointing out that these bitwise operations are *lightning*
fast for computers to do. They're extremely efficient. CPUs have
dedicated circuitry to do them.
Let's get back to Debian for a moment.
Debian doesn't use "iwd" (whatever that is) to configure network
interfaces. Whatever created this file, it's not being used.
Debian uses /etc/network/intefaces, which is a file documented by
the man page interfaces(5). Any interface that's correctly defined in
this file will be configured by it.
If network-manager (NM) is installed, it will try to configure any
interfaces that are *not* defined in /etc/network/interfaces. On some
systems, this means NM is the primary means of configuring interfaces.
On others, it may only do the wireless interfaces, while /e/n/i does
the ethernet ones. On still other systems, NM might do nothing, or it
might not even be installed at all.
Debian also allows you to configure interfaces using some crazy systemd
thing. This isn't done by any of the supported installation task sets.
But if you choose, you could read the systemd man pages and figure out
how to do it this way, and then do it.
Reply to: