dmesg shows strange entries [tcpflags 0x10<ACK>; sending RST; tcp_do_segment... ]

francis

francis

Hi all. I have strange situation with dmesg command. When I want to check something about computer devices, dmesg shows nothing. [CMD=""]#dmesg |grep cd[/CMD] and I dont see any information, just #. A few days ago, everything was okay.

Now, after using this command, I see many entries similar to this: [CMD=""]#dmesg[/CMD]
Code: 
TCP: [216.14.102.17]:80 to [192.168.1.101]:31644 tcpflags 0x10<ACK>; 
tcp_do_segment: FIN_WAIT_2: Received 1460 bytes of data after socket was closed, 
sending RST and removing tcpcb
Connection attempt to UDP 192.168.1.101:13615 from 208.67.222.222:53
TCP: [127.0.0.1]:47303 to [127.0.0.1]:25 tcpflags 0x2<SYN>; 
tcp_input: Connection attempt to closed port
tcp_do_segment: FIN_WAIT_1: Received 1460 bytes of data after socket was closed,
sending RST and removing tcpcb
And these entries is many more!
I checked dmesg.today file in /var/log/ directory with tail command. [CMD=""]#tail -f dmesg.today[/CMD]
Code: 
TCP: [87.98.235.118]:80 to [192.168.1.101]:21147 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: 
Received 281 bytes of data after socket was closed, 
sending RST and removing tcpcb
TCP: [46.4.240.9]:80 to [192.168.1.101]:50581 tcpflags 0x12<SYN,ACK>; tcp_input: 
Connection attempt to closed port
TCP: [46.4.240.9]:80 to [192.168.1.101]:63366 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_2: 
Received 1460 bytes of data after socket was closed, 
sending RST and removing tcpcb
Connection attempt to UDP 192.168.1.101:68 from 192.168.X.X:67
This information about attempt to UDP is probably normal, because I dont have any rules in packet filter for DHCP, because of bpf and configuring network during system start. Everything works okay, if it is about network.
Why dmesg command shows only information about socket, RST, connection to closed port, instead of computer information?
 
dmesg reads a buffer that can be filled by other processes (like the things you mention), which means that the 'original' information (the boot sequence) will be pushed out of the buffer.

You should however have a /var/run/dmesg.boot which does contain the last boot sequence.
 
So, everything is okay?

And what do You think about [CMD=""]#dmesg |grep cd/dvd/usb etc.[/CMD]

It is also normal, that dmesg does not show information about the devices?
Yes, I have a dmesg.boot file in /var/run/ directory, and contains info about computer, which I see on system boots, but not everything.
 
Yes, it is normal. As I said, the buffer used by dmesg can be used by/for other things. The only way to get more information than is available in /var/run/dmesg.boot is to reboot and run dmesg -a > somefile immediately thereafter.
 
Okay, thanks for the explanation. I never saw such a result of dmesg command.

But please, tell me one more thing. It is normal that I have this result of sockstat command [CMD=""]#sockstat -4[/CMD]
Code: 
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
smmsp    sendmail   3002  6  tcp4   127.0.0.1:53765       127.0.0.1:25
smmsp    sendmail   2998  6  tcp4   127.0.0.1:20839       127.0.0.1:25
when sendmail is complete disable via rc.conf file? I mean
Code: 
sendmail_enable/outbound/msp_queue="NO"
 
Yes, I know that. But believe me or not, even with
Code: 
sendmail_enable="NONE"
I have got that message. Or may I am wrong? :)

But, option NONE does not makes sendmail disappear from top command only, but it will be loaded as a daemon? And option NO does not makes sendmail daemon will be not loaded on startup?

Okay, nevermind. I wonder only, if this is normal behaviour.
I do not have nothing to worry about, right?
 
francis said:
Code: 
# sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
smmsp    sendmail   3002  6  tcp4   127.0.0.1:53765       127.0.0.1:25
smmsp    sendmail   2998  6  tcp4   127.0.0.1:20839       127.0.0.1:25

Okay, nevermind. I wonder only, if this is normal behaviour.
I do not have nothing to worry about, right?
Click to expand...

Since local and foreign addresses are both on localhost, I'd guess it's just sendmail trying to deliver status reports. But it should go away; maybe it's trying to deliver to a nonexistent user.

Realize also that just changing the entries in /etc/rc.conf won't change anything on the running system. They only take effect when services are started or stopped, like at system startup and shutdown.

% sendmail -bp
might show something useful.
 
You must log in or register to reply here.
Back
Top