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? -- Len Sorensen ------------------------------------------------------------------------------ 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
