search for: estab

...see bellow, the ports are also available tcp LISTEN 0 128 *:24007 *:* tcp TIME-WAIT 0 0 192.168.1.8:49110 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168.1.8:49081 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168.1.8:49118 192.168.1.8:24007 tcp ESTAB 0 0 192.168.1.8:49146 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168.1.8:49104 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168.1.8:49094 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168.1.8:49097 192.168.1.8:24007 tcp TIME-WAIT 0 0 192.168....

...; tcp LISTEN 0 128 *:24007 > *:* > tcp TIME-WAIT 0 0 192.168.1.8:49110 > 192.168.1.8:24007 > tcp TIME-WAIT 0 0 192.168.1.8:49081 > 192.168.1.8:24007 > tcp TIME-WAIT 0 0 192.168.1.8:49118 > 192.168.1.8:24007 > tcp ESTAB 0 0 192.168.1.8:49146 > 192.168.1.8:24007 > tcp TIME-WAIT 0 0 192.168.1.8:49104 > 192.168.1.8:24007 > tcp TIME-WAIT 0 0 192.168.1.8:49094 > 192.168.1.8:24007 > tcp TIME-WAIT 0 0 192.168.1.8:49097 > 192.168.1.8:24007 >...

...*:24007 >> *:* >> tcp TIME-WAIT 0 0 192.168.1.8:49110 >> 192.168.1.8:24007 >> tcp TIME-WAIT 0 0 192.168.1.8:49081 >> 192.168.1.8:24007 >> tcp TIME-WAIT 0 0 192.168.1.8:49118 >> 192.168.1.8:24007 >> tcp ESTAB 0 0 192.168.1.8:49146 >> 192.168.1.8:24007 >> tcp TIME-WAIT 0 0 192.168.1.8:49104 >> 192.168.1.8:24007 >> tcp TIME-WAIT 0 0 192.168.1.8:49094 >> 192.168.1.8:24007 >> tcp TIME-WAIT 0 0 192.168.1.8:49097 >...

...re anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTAB LISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:s sh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:h ttp ACCEPT tcp -- anywhere anywhere state NEW tcp...

...pts to open a new connection for incoming authentication requests, judging from the fact that it keeps trying to do DC location (but fails, because both candidate DCs are stuck in NEG_CONN_CACHE for some reason, even if they're answering request from, e.g., adcli). There is already an RPC pipe (ESTAB connection to port 49159 on DC), but Winbind seems to insist on opening a new connection and doesn't reuse existing. Am I misinterpreting something? I thought Winbind is supposed to open a new connection only when existing one is busy with some request? -------------- next part -------------- A...

...> answering request from, e.g., adcli). You should try to find out the request that caused them to get put into the NEG_CONN_CACHE. In winbindd, look at the calls to winbind_add_failed_connection_entry() - there are several reasons that this might get called. > There is already an RPC pipe (ESTAB connection to port 49159 on DC), but > Winbind seems to insist on opening a new connection and doesn't reuse existing. > Am I misinterpreting something? I thought Winbind is supposed to open a new connection only when existing one is busy with some request? 'winbind max domain connec...

...tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:25151 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTAB LISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-po rt-unreachable REJECT all -- anywhere anywhe...

...ID/GID queries and not unavailable DCs. Specifically the issue I've ran into recently is that with 'winbind max domain connections' set to 10 I saw Winbind had single active connection to the DC on port 49159 (RPC pipe from LSA/SAM/NetLogon, from what I understand), but it was trying to establish a second connection to serve incoming auth request and it was failing to do so during DC location, because at some point it tried to do NetLogon ping to both DCs (doman has only two) and for both the ping timed out, and then it put both DCs into negative cache and during DC location process was...

...we are bumping into an issue where the kernel doesn''t clean up connections after an application exits. When this issue occurs, the netstat utility doesn''t show anything listening on the port the application uses (8080 in the example below), but connections are still listed in the ESTABLISHED state: $ netstat -an | grep LISTEN *.22 *.* 0 0 49152 0 LISTEN 127.0.0.1.25 *.* 0 0 49152 0 LISTEN 127.0.0.1.587 *.* 0 0 49152 0 LISTEN $ netstat -an | grep ESTAB | gr...

...and the ip_conntrack timer is reset to 5 minutes. The criteria for being the "same" is based on the TCP sequence number and acknowledgement number, but does not include the TCP window size advertisement. Sample occurance : Extract from /proc/net/ip_conntrack 08:46:51.811 431999 ESTABLISHED src=192.168.81.245 dst=192.168.49.30 sport=48610 dport=8009 08:47:01.532 431998 ESTABLISHED src=192.168.81.245 dst=192.168.49.30 sport=48610 dport=8009 08:47:01.920 000299 ESTABLISHED src=192.168.81.245 dst=192.168.49.30 sport=48610 dport=8009 08:47:02.925 000298 ESTABLISHED src=1...

Hello, I''ve several problems with quota on our testcluster: When I set the quota for a person to a given value (e.g. the values which are provided in the operations manual), I''m able to write exact the amount which is set with setquota. But when I delete the files(file) I''m not able to use this space again. Here is what I''ve done in detail: lfs checkquota