On a side note: There may be others here who are willing to chime in. For me this would be the most consumer-friendly method that doesn't involve to much effort.īut like many things in life, don't go in blind on the advice of others, but stop and think if this all sound logical. Think Panopticlick, the tool mentioned earlier, some tcp analyses with the help of Wireshark, and so on. Then test everything before trying Reddit again. (Don't forget to check how you are NAT'ed on your local network.) 8.8.8.8) For this purpose you can either use a VPN or get your hands on some residentials and configure these inside the VM. Just make sure that your VM's don't share the same IP as your host and perhaps change one or two DNS settings (i.e. add a couple of different browser extensions to each of the individual browsers.
If it involves a single account I would try one or two VM's each running a different OS with slighty different settings. upvoting your own posts in the initial stage.) If true, you can stop the mksysb process and kill “backbyname” on the Client LPAR if it remains running after stopping mksysb.Are we talking about a single (shadow) banned account or multiple accounts? (i.e. You can confirm the mksysb is hanging when there is no progress seen in the mksysb file size and the “backbyname” is still running on the Client LPAR: To verify the value is set, use # no -a | grep keep To change the value on your AIX system use: IBM does not offer recommendations on what the value should be, but its good if it's not less than 15 minutes or 1800 half seconds. The default is 14400 half seconds which are 2 hours. To fix this, your firewall's TCP timeout window must be increased to match the longest time it may take for an mksysb operation to complete.Īs a workaround, the TCP keepalive settings on AIX may be tuned, the most common one is tcp_keepidle, this attribute is responsible for the time it takes for AIX to start sending keepalive packages on idle sessions. This is generally caused by the TCP timeout setting on your firewall, because the AUX session may remain idle for a long time, depending on how long it takes for the mksysb to complete, some firewalls may consider the session inactive and drop it. WireShark analysis will show retransmissions for the "FIN" package on the NIM AUX port 3902: If the packages are missing from the NIM side, it means they were dropped in between the two LPARs, most likely by a firewall. You can verify the NIM is not receiving those packages by looking for the same package ID on the NIM side of the trace. You can use a tool like Wireshark to open the trace files and analyze the data, you need to look for “Retrasmission” packages on the client side of the trace and on port 3902, those indicate the client LPAR is trying to send out something to NIM, but is not getting a reply.
WOW TROUBLESHOOTING IPTRACE FREE
*Before starting ensure you have at least 500MB free in the /tmp file system. To diagnose this problem, we will need to take a iptrace/tcpdump from both the NIM LPAR and the Client LPAR during the hanging operation.
0 kommentar(er)
