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



## francis (Jan 21, 2011)

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] 
	
	



```
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] 
	
	



```
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?


----------



## DutchDaemon (Jan 22, 2011)

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.


----------



## francis (Jan 22, 2011)

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.


----------



## DutchDaemon (Jan 23, 2011)

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.


----------



## francis (Jan 23, 2011)

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] 
	
	



```
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 
	
	



```
sendmail_enable/outbound/msp_queue="NO"
```


----------



## wblock@ (Jan 23, 2011)

sendmail_enable="NO" does not completely disable sendmail.  That's sendmail_enable="NONE".


----------



## francis (Jan 23, 2011)

Yes, I know that. But believe me or not, even with 
	
	



```
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?


----------



## wblock@ (Jan 23, 2011)

francis said:
			
		

> ```
> # 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
> ...



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.


----------

