-
Notifications
You must be signed in to change notification settings - Fork 712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unexpected edge between "Inbound" and "Outbound" #1110
Comments
Can we have a report please?
@pidster decided on the naming. |
Did I? |
@tomwilkie issue #566 (comment) refers to "connections". If I indicated 'requests' elsewhere, this was an error on my part. I think "connections" is more appropriate. I filed #1111 |
Tom reckons the cause could be related to #1122. But note that I did not make any adjustments to scope timing parameters here - the above is from a straight, single-host "scope launch". |
Here is another, shorter, report. This is from a vanilla scope, current master. I have no containers besides scope. And here are some screenshots... The 192.168.3.22 IP showing up in the Outbound connections of the "Inbound Internet" is not pingable. The two IPs (192.30.252.91 and 216.58.214.14) showing up in the Inbound connections of the "Outbound Internet" are pingable. 192.168.3.22 and 192.30.252.91 do not show up in Here are my machine's network interfaces:
And here is my routing table:
|
I believe this procspy rate limiting again... |
Note that I do not see an 'Inbound connections' node in the Process view. Doesn't that discrepancy with the Container view point to a logic bug rather than data collection timing issue? |
The stray connections do appear in I was unable to reproduce this issue at work, only at home. With the same machine. Also, after rebooting my machine at home, and running all my usual apps, the problem went away. I have a theory... perhaps conntrack entries are not removed when my IP address changes when I relocate from the offoce to home? So the 192.168.3.22 should be my IP address at the office. I shall find out tomorrow :) This would explain why the conntrack entries have that as the src IP and are for destinations ips/ports of the services for all the usual apps I am running, e.g. spotify, xmpp. Since that IP is not on my home network, scope treats it as an "Internet" IP. |
It could be, but it shouldn't. Conntrack-gathered connections shouldn't appear as edges unless one of the sides matches the IP of a container, right @tomwilkie ? |
What's the status of the flows from |
iirc it was 'ESTABLISHED'. |
Uhm, I think that the problem might be ESTABLISHED flows lingering because of nf_conntrack_tcp_timeout_established which defaults to 5 days. For instance, in my system:
However, that flow disappears when the connection is not established anymore. |
It is. |
Here's an example
|
Can we get the xml with the timeout? |
how? |
|
(if my memory serves correctly) |
Also, the output of |
The timeout is the third column, i.e. 431924 in the above. |
|
|
My bad, thanks :) |
15 of the 89 connections have my office IP as the src. |
Either I don't understand conntrack and flows are supposed to linger in some situations or there's a conntrack bug. I think that the next step is to ask the netfilter guys. Maybe there's a problem due to the laptop being suspended ... who knows. |
Observed on my laptop: Scope report for "The Internet (Inbound connections)"
Scope report for "The Internet (Outbound connections)"
conntrack
|
192.168.1.83 is my laptop's IP address.
|
Looks like 192.168.3.173 was my old IP address on wifi, apparently. |
Yep, the key question is: Why do those flows linger when the connections clearly don't exist anymore? Maybe I don't understand conntrack properly but that sounds like a bug to me. |
I've run into this for the first time, on my development VM. I had to run My VM uses a reasonable recent kernel:
|
filter internet adjacencies Fixes #1110.
That edge should not be there, right?
Also, what is 'Requests' supposed to mean?
The text was updated successfully, but these errors were encountered: