Le 26/12/2017 à 16:05, Mark Fletcher a écrit :
At the risk of further advertising my ignorance, 3 as an 8-bit binary is
00000011, and 252 in binary is 11111100, so why doesn't that mask "fit"
with that address? (if you'll pardon my poor terminology) Put another
way, why do I need to zero out another bit of the mask to make .3 a
unicast address?
The IPv4 protocol specification gives a special meaning to the first and
last addresses in a subnet. The first address is the "network address"
and the last address is the "broadcast address". Both are reserved and
cannot be used as unicast host address.
The only exception is for /31 prefixes on "point to point" links. Such
networks contain only a pair of address, so the usual rule would reserve
them as network and broadcast addresses and and leave no usable host
address, making the prefix useless in practice. Instead, both addresses
are used as host addresses for the nodes at each end of the point to
point link, and there are no network and broadcast addresses (pointless
on a point to point link). This exception was created to avoid the use
of /30 prefixes on such point to point links which would waste half of
the addresses. Note that old devices and systems may not support this.
But why do you bother with such narrow subnets and just don't use
255.255.255.0 (/24) ? It has been reported that some devices and OSes don't
behave well with "unusual" netmasks (having values other than 255 and 0).
Totally fair question. No good reason these days. I am happy to change
it.
IIUC, you declared subnet 192.168.1.0/30 or /29 in the DHCP server
configuration. But what subnet or prefix lenght did you set up on the
interface configuration of the firewall and server ?
Also, I recommend that you run a packet capture on the firewall and the
server to see what's going on when you try to communicate to the server from
the internal network.
tcpdump -nei <interface>
Yes, this is going to be my next port of call (after I've opened up the
netmask to 255.255.255.0). Since both the PI and the firewall are LFS I
will probably have to build the tcpdump program for them both as there
is nothing installed on either of them that isn't strictly needed.
Sorry for the extra burden.
Running a packet sniffer on another (e.g. Debian) machine on the
external subnet would only capture broadcast packets, except if your
ethernet switch supports a "mirror port" feature which mirrors incoming
traffic on all ports to a special port for monitoring purpose.
Using iptables LOG rules in raw/PREROUTING and mangle/POSTROUTING on the
router and the server would log only IPv4 packets, not ARP packets which
could provide valuable information. Maybe by combining the two you could
gather enough data.
