The printer uses its fe80:: address to contact the DHCPv6 server which
is handing out 2001:470:?:?::/64 addresses.
The DROP in the mangle table worked.
I still would like to know why fe80:: traffic is neither forwarded nor sent
to the INPUT chain.
Firmware update: I don't want to go this route. The printer is happy
with its IPv4 address. It doesn't have to speak IPv6.
Bill
On 4/18/2018 9:24 AM, Lennart Sorensen wrote:
On Wed, Apr 18, 2018 at 08:39:09AM -0400, Bill Shirley wrote:
[0:root@c3po my.tables]$ rpm -q shorewall6
shorewall6-5.0.14.1-1.fc24.noarch
I have a HP printer that's mis-behaving. It gets an IPv4 address from DHCP and
is happy.
However for some reason after getting an IPv6 address, it doesn't like what it
got and
asks for an address again. This happens over and over thus generating a lot of
traffic
and filling the log file.
I tried telling DHCP6 to ignore it with no joy. Solution: ip6tables
But after adding a DROP (tried LOG too) statement in rules, the rule never
matches.
Ok, now debug in mangle mode. mangle:
?COMMENT fe80icmp tcpre DEBUG
MARK($JUNK_MARK/$JUNK_MARK):P [fe80::1ec1:deff:fec7:70fe] - icmp
MARK($JUNK_MARK/$JUNK_MARK):P $NPIC770FE_mac - icmp
?COMMENT fe80udp tcpre DEBUG
MARK($JUNK_MARK/$JUNK_MARK):P [fe80::1ec1:deff:fec7:70fe] - udp
MARK($JUNK_MARK/$JUNK_MARK):P $NPIC770FE_mac - udp
?COMMENT fe80udp tcin DEBUG
MARK($JUNK_MARK/$JUNK_MARK) [fe80::1ec1:deff:fec7:70fe] $FW
MARK($JUNK_MARK/$JUNK_MARK) $NPIC770FE_mac $FW
?COMMENT fe80udp tcfor DEBUG
MARK($JUNK_MARK/$JUNK_MARK):F [fe80::1ec1:deff:fec7:70fe] -
MARK($JUNK_MARK/$JUNK_MARK):F $NPIC770FE_mac -
tcpdump shows the printer's traffic:
07:15:41.737968 1c:c1:de:c7:70:fe > 33:33:00:01:00:02, ethertype IPv6
(0x86dd), length 133: fe80::1ec1:deff:fec7:70fe.546 > ff02::1:2.547: dhcp6
solicit
07:15:42.464350 1c:c1:de:c7:70:fe > 33:33:00:00:01:16, ethertype IPv6
(0x86dd), length 86: fe80::1ec1:deff:fec7:70fe > ff02::116: HBH ICMP6,
multicast listener reportmax resp delay: 0 addr: ff02::116, length 24
07:15:42.822517 1c:c1:de:c7:70:fe > 33:33:ff:c7:70:fe, ethertype IPv6
(0x86dd), length 86: fe80::1ec1:deff:fec7:70fe > ff02::1:ffc7:70fe: HBH
ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ffc7:70fe,
length 24
ip6tables -t mangle shows the traffic in tcpre but nothing after that:
Chain tcfor (1 references)
0 0 MARK all * * fe80::1ec1:deff:fec7:70fe ::/0
/* fe80udp tcfor DEBUG */ MARK or 0x800000
0 0 MARK all * * ::/0
::/0 MAC 1C:C1:DE:C7:70:FE /* fe80udp tcfor DEBUG */ MARK or
0x800000
Chain tcin (1 references)
0 0 MARK all * * fe80::1ec1:deff:fec7:70fe ::/0
/* fe80udp tcin DEBUG */ MARK or 0x800000
0 0 MARK all * * ::/0
::/0 MAC 1C:C1:DE:C7:70:FE /* fe80udp tcin DEBUG */ MARK or
0x800000
Chain tcout (1 references)
Chain tcpost (1 references)
Chain tcpre (1 references)
2 144 MARK icmpv6 * * fe80::1ec1:deff:fec7:70fe
::/0 /* fe80icmp tcpre DEBUG */ MARK or 0x800000
2 144 MARK icmpv6 * * ::/0
::/0 MAC 1C:C1:DE:C7:70:FE /* fe80icmp tcpre DEBUG */ MARK
or 0x800000
1 119 MARK udp * * fe80::1ec1:deff:fec7:70fe ::/0
/* fe80udp tcpre DEBUG */ MARK or 0x800000
1 119 MARK udp * * ::/0
::/0 MAC 1C:C1:DE:C7:70:FE /* fe80udp tcpre DEBUG */ MARK or
0x800000
Why to the packets disappear? I even did a "-j TRACE":
Apr 18 06:21:58 c3po kernel: TRACE: raw:PREROUTING:policy:9 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79
Apr 18 06:21:58 c3po kernel: TRACE: mangle:PREROUTING:rule:1 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79
Apr 18 06:21:58 c3po kernel: TRACE: mangle:tcpre:rule:3 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79
Apr 18 06:21:58 c3po kernel: TRACE: mangle:tcpre:rule:4 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79 MARK=0x800000
Apr 18 06:21:58 c3po kernel: TRACE: mangle:tcpre:rule:14 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79 MARK=0x800000
Apr 18 06:21:58 c3po kernel: TRACE: mangle:PREROUTING:policy:2 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79 MARK=0x800000
Apr 18 06:21:58 c3po kernel: TRACE: nat:PREROUTING:policy:2 IN=lan OUT=
MAC=33:33:00:01:00:02:1c:c1:de:c7:70:fe:86:dd
SRC=fe80:0000:0000:0000:1ec1:deff:fec7:70fe
DST=ff02:0000:0000:0000:0000:0000:0001:0002 LEN=119 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=546 DPT=547 LEN=79 MARK=0x800000
After the mangle table, packets are absorbed somewhere.
Anyone have any insight?
Next, I'll try to DROP in the mangle tcpre.
fe80 addresses are link local addresses and not useful for normal traffic,
so I could see why it would like something else. Usually devices pick
their fe80 address themselves. Certainly dhcpv6 is NOT allowed to hand
out fe80 addresses.
If you have dhcpv6 running, what addresses are you actually handing out
to the network?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
