Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
Re: [opensuse] What is the meaning of these firewall log entries?
On 2016-02-13 18:27, Darryl Gregorash wrote:
On 13/02/16 08:26 AM, Carlos E. R. wrote:

I think that it is not that the receiver has the port closed, but that
the sender machine is halting its own network service causing spurious
log entries on the firewall (when packets can not be sent by the
kernel netconsole), with incorrect content.

If the sender machine (Telcontar is ...14, I am assuming)

Correct.

has halted its
network, then its firewall should be closed to all traffic, outbound as
well as inbound. In that case, nothing should be reaching ...15, so
there should be no "port unreachable" replies from that system.

Yep.

At most,
you should be seeing default dropped *outbound* packets addressed to
port 6666 on ....15, not ICMP responses from the remote system.

Very, very very strange..... to make sense of this, we are almost
required to believe that Telcontar is dropping outbound UDP packets, but
instead is logging incoming ICMP responses which are being dropped and
logged.

If you have the time, would you be willing to log *all* firewall traffic
on *both* systems, and then wade through both logs to see if there is
any additional evidence to suggest what is going on? That will be a lot
of work, I know, but it may be the only way we will be able to get to
the bottom of this.

A tcp dump? Or tell SuSEfirewall2 to log everything?

FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="no"
FW_LOG_ACCEPT_CRIT="no"
FW_LOG_ACCEPT_ALL="no"

I can set all of them to "yes" prior to hibernation, and undo after. It is
simple to do.


I need to code something first. I need a pipe that receives text entries, and
writes them to stdout prefixed with a timestamp.
I coded this years ago, but apparently I lost it. I know how to do it, just
that I wanted to avoid it.


On 2016-02-13 18:38, Darryl Gregorash wrote:
On 13/02/16 07:49 AM, Carlos E. R. wrote:
On 2016-02-13 13:32, Darryl Gregorash wrote:
On 12/02/16 11:47 PM, Andrei Borzenkov wrote:

During all this time, on 192.168.1.15 there is a "netcat -u -l 6666 | tee -a
remote_log" process logging entries coming from 192.168.1.14, by netconsole,
which TODAY is indeed working, as I got entries in the remote_log file:


[1086086.299979] Syncing filesystems ... [1086086.299979] Syncing
filesystems ... done.
[1086086.828979] Freezing user space processes ...
[1086086.829327] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=00:21:85:16:2d:0b:00:03:0d:05:17:fc:08:00 SRC=192.168.1.15
DST=192.168.1.14 LEN=62 TOS=0x00 PREC=0xC0 TTL=64 ID=52521 PROTO=ICMP TYPE=3
CODE=3 [SRC=192.168.1.14 DST=192.168.1.15 LEN=34 TOS=0x00 PREC=0x00 TTL=64
ID=3399 PROTO=UDP SPT=6666 DPT=6666 LEN=14 ]
[1086086.830161] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=00:21:85:16:2d:0b:00:03:0d:05:17:fc:08:00 SRC=192.168.1.15
DST=192.168.1.14 LEN=107 TOS=0x00 PREC=0xC0 TTL=64 ID=52522 PROTO=ICMP
TYPE=3 CODE=3 [SRC=192.168.1.14 DST=192.168.1.15 LEN=79 TOS=0x00 PREC=0x00
TTL=64 ID=3401 PROTO=UDP SPT=6666 DPT=6666 LEN=59 ]
...
...
[1086096.119680] Restarting kernel threads ... done.
[1086096.125260] Restarting tasks ... done.

So everything is working now, except those dropped ICMP messages despite the
port being open, and the packages being accepted and logged. But only during
the hibernation process.


These log entries are from ...14, yes?

Yes.

If these are being sent by ...15,
perhaps that system might have corresponding log entries to indicate why
the ICMP packets are being sent in the first place.

Not in the firewall log. The instant of interest is 06:30:37:


<3.6> 2016-02-13T06:20:01.030169+01:00 AmonLanc systemd 1 - - Started Session
6981 of user root.
<3.3> 2016-02-13T06:29:18.004882+01:00 AmonLanc nmbd 2044 - - [2016/02/13
06:29:18.004425, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_n
<3.3> 2016-02-13T06:29:18.005770+01:00 AmonLanc nmbd 2044 - -
find_domain_master_name_query_fail:
<3.3> 2016-02-13T06:29:18.006400+01:00 AmonLanc nmbd 2044 - - Unable to find
the Domain Master Browser name VALINOR<1b> for the workgroup VALINOR.
<3.3> 2016-02-13T06:29:18.006963+01:00 AmonLanc nmbd 2044 - - Unable to sync
browse lists in this workgroup.
<3.6> 2016-02-13T06:30:01.388548+01:00 AmonLanc systemd 1 - - Starting Session
6982 of user root.
<3.6> 2016-02-13T06:30:01.390475+01:00 AmonLanc systemd 1 - - Started Session
6982 of user root.
<3.6> 2016-02-13T06:30:01.421528+01:00 AmonLanc systemd 1 - - Starting Session
6983 of user root.
<3.6> 2016-02-13T06:30:01.423313+01:00 AmonLanc systemd 1 - - Started Session
6983 of user root.
<3.6> 2016-02-13T06:40:02.031776+01:00 AmonLanc systemd 1 - - Starting Session
6984 of user root.
<3.6> 2016-02-13T06:40:02.036370+01:00 AmonLanc systemd 1 - - Started Session
6984 of user root.
<3.3> 2016-02-13T06:44:23.767151+01:00 AmonLanc nmbd 2044 - - [2016/02/13
06:44:23.766771, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_n



The nmbd entries are unrelated, I see more entries all the time.


If ...15's firewall
is open on port 6666, there is no reason at all why it should be sending
"port unreachable" responses. Since there is something listening on that
port on that system, there should be no ICMP messages from ..15 to ..14
at all.

=-O
:-\
:'(
(I can't find a smiley for "tearing my hair out" so I picked 3
alternates ;) )


Yes, that's the curious thing about it.
My hypothesis is that it goes nuts while Telcontar is handling the start into
hibernation and the network interface is closed.
The "netconsole" thing is pretty low level in the kernel, because it has to
work when other things do not work.


--
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

< Previous Next >