Search Results

Search found 199 results on 8 pages for 'nop at nada'.

Page 1/8 | 1 2 3 4 5 6 7 8  | Next Page >

• TCP RST right after FIN/ACK

  - by Nitzan Shaked

  I am having the weirdest issue: I have a web server which sometimes, only on very specific requests, will send a RST to the client after having sent the FIN datagram. First, a description of the setup: The server runs on an Ubuntu 12.04.1 LTS, which itself is a VM guest inside a Win7 x64 host, in bridged mode. ufw is disabled on the host The client runs on a iOS simulator, which runs on OS X Mountain Lion, which is a VM guest (hackintosh) inside a Win7 x64 host, in bridged mode. Both client and server are on the same LAN, one is connected to the home router via an Ethernet cable, and then other thru WiFi. I happened to glimpse over the server's http logs and found that the client sometimes issuing multiple subsequent identical requests. Further investigation led me to discover that this happens when the server sends a RST, and that the client is simply re-trying. I am attaching several tcpdump's: Good1 is the server-side tcpdump of a good session ("good" meaning no RST was generated). Good3 is another sever-side tcpdump of a good session. (The difference between Good1 and Good3 is the order in which ACK's were sent from the server to the client, ACK'ing the client's request. The client's request arives in 2 segements (specifically: one for the http headers, and another for a body containing an empty json object, "{}"). In Good1, the server ACK's both request segments, using 2 ACK segments, after the second request has arrived. In Good3, the server ACK's each request segment with an ACK segment as soon as the request segment arrives. Not that it should make a difference.) Bad1 is a dump, both client- and server-side, of a bad session. Bad2 is another bad session, this time server-side only. Note that in all "bad" sessions, the server ACK's each request segments immediately after having received it. I've looked at a few other bad sessions, and the situation is the same in all of them. But this is also the behavior in "Good3", so I don't see how that observation helps me, of for that matter why it should matter. I can't find any difference between good and bad sessions, or at least one that I think should matter. My question is: why are those RST's being generated? Or at least: how do I go about debugging this, or providing more info here that'll help? Edit 2 new facts that I have learned: Section 4.2.2.13 of the RFC (1122) (and Wikipedia, in the article "TCP", under "Connection Termination") says that a TCP application on one host may close the connection before it has read all of the data in its socket buffer, and in such a case the TCP on the host will sent a RST to the other side, to let it know that not all the data it has sent has been read. I'm not sure I completely understand this, since closing my side of the connection still allows me to read, no? It also means that I can't write any more. I am not sure this is relevant, though, since I see a RST after FIN. There are multiple complaints of this happening with wsgiref (Python's dev-mode HTTP server), which is exactly what I'm using. I'll keep updating as I find out more. Thanks! ~~~~~~~~~~~~~~~~~~~~ Good1 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:02.308319 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [S], seq 94268074, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943308864 ecr 0,sackOK,eol], length 0 13:28:02.308336 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [S.], seq 1726304574, ack 94268075, win 14480, options [mss 1460,sackOK,TS val 326480982 ecr 943308864,nop,wscale 3], length 0 13:28:02.309750 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 0 13:28:02.310744 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 350 13:28:02.310766 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 2 13:28:02.310841 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480983 ecr 943308865], length 0 13:28:02.310918 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480983 ecr 943308865], length 0 13:28:02.315931 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480984 ecr 943308865], length 17 13:28:02.316107 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480984 ecr 943308865], length 666 13:28:02.317651 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318288 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318640 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [F.], seq 353, ack 685, win 8192, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318651 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 354, win 1944, options [nop,nop,TS val 326480985 ecr 943308872], length 0 ~~~~~~~~~~~~~~~~~~~~ Good3 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:03.311143 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [S], seq 1982901126, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943309853 ecr 0,sackOK,eol], length 0 13:28:03.311155 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [S.], seq 2245063571, ack 1982901127, win 14480, options [mss 1460,sackOK,TS val 326481233 ecr 943309853,nop,wscale 3], length 0 13:28:03.312671 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943309854 ecr 326481233], length 0 13:28:03.313330 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943309855 ecr 326481233], length 350 13:28:03.313337 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326481234 ecr 943309855], length 0 13:28:03.313342 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943309855 ecr 326481233], length 2 13:28:03.313346 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326481234 ecr 943309855], length 0 13:28:03.327942 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326481237 ecr 943309855], length 17 13:28:03.328253 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326481237 ecr 943309855], length 666 13:28:03.329076 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943309868 ecr 326481237], length 0 13:28:03.329688 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943309868 ecr 326481237], length 0 13:28:03.330361 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [F.], seq 353, ack 685, win 8192, options [nop,nop,TS val 943309869 ecr 326481237], length 0 13:28:03.330370 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 354, win 1944, options [nop,nop,TS val 326481238 ecr 943309869], length 0 ~~~~~~~~~~~~~~~~~~~~ Bad1 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:01.311876 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [S], seq 920400580, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307883 ecr 0,sackOK,eol], length 0 13:28:01.311896 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [S.], seq 3103085782, ack 920400581, win 14480, options [mss 1460,sackOK,TS val 326480733 ecr 943307883,nop,wscale 3], length 0 13:28:01.313509 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307884 ecr 326480733], length 0 13:28:01.315614 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 350 13:28:01.315727 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:01.316229 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 2 13:28:01.316242 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:01.321019 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480735 ecr 943307886], length 17 13:28:01.321294 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 666 13:28:01.321386 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 0 13:28:01.322727 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307891 ecr 326480735], length 0 13:28:01.322733 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103085800, win 0, length 0 13:28:01.323221 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307892 ecr 326480736], length 0 13:28:01.323231 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103086467, win 0, length 0 ~~~~~~~~~~~~~~~~~~~~ Bad1 -- Client Side ~~~~~~~~~~~~~~~~~~~~ 13:28:11.374654 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [S], seq 920400580, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307883 ecr 0,sackOK,eol], length 0 13:28:11.375764 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [S.], seq 3103085782, ack 920400581, win 14480, options [mss 1460,sackOK,TS val 326480733 ecr 943307883,nop,wscale 3], length 0 13:28:11.376352 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307884 ecr 326480733], length 0 13:28:11.378252 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 350 13:28:11.379027 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 2 13:28:11.379732 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:11.380592 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:11.384968 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480735 ecr 943307886], length 17 13:28:11.385044 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307891 ecr 326480735], length 0 13:28:11.385586 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 666 13:28:11.385743 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307892 ecr 326480736], length 0 13:28:11.385966 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 0 13:28:11.387343 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103085800, win 0, length 0 13:28:11.387344 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103086467, win 0, length 0 ~~~~~~~~~~~~~~~~~~~~ Bad2 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:01.319185 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [S], seq 1631526992, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307889 ecr 0,sackOK,eol], length 0 13:28:01.319197 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [S.], seq 2524685719, ack 1631526993, win 14480, options [mss 1460,sackOK,TS val 326480735 ecr 943307889,nop,wscale 3], length 0 13:28:01.320692 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 0 13:28:01.322219 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 350 13:28:01.322336 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480736 ecr 943307890], length 0 13:28:01.322689 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 2 13:28:01.322700 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307890], length 0 13:28:01.326307 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 17 13:28:01.326614 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 666 13:28:01.326710 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 0 13:28:01.328499 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307896 ecr 326480737], length 0 13:28:01.328509 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R], seq 2524685737, win 0, length 0 13:28:01.328514 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307896 ecr 326480737], length 0 13:28:01.328517 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R], seq 2524686404, win 0, length 0

  Read the article

• Millions of SYN_RECV connections, no DDoS

  - by ThomK

  We have such server structure: reverse proxy (nginx) - worker (uwsgi) - postgresql / memcached. All servers are in local network behind router, with NATed external ip:ports (http/s 80/443 to proxy, and ssh 22 to all servers). Problem is, that sometimes proxy server netstat reports MILLIONS of SYN_RECV connections. From same IP / same ports. Like that: nginx ~ # netstat -n | grep 83.238.153.195 tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV tcp 0 0 192.168.1.1:80 83.238.153.195:3107 SYN_RECV [...] And this is not DDoS, because all IPs affected belongs to our website users. On side note, users says that it's not affecting them. Website is online and working, but... that particular one (from example above) told me that website is down and Firefox can't connect. I've done tcpdump. 19:42:14.826011 IP 83.238.153.195.zephyr-srv > 192.168.1.1.http: Flags [S], seq 1845850583, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:14.826042 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:17.887331 IP 83.238.153.195.zephyr-srv > 192.168.1.1.http: Flags [S], seq 1845850583, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:17.887343 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:19.065497 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:23.918064 IP 83.238.153.195.zephyr-srv > 192.168.1.1.http: Flags [S], seq 1845850583, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:23.918076 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:25.265499 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:37.265501 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:37.758051 IP 83.238.153.195.2107 > 192.168.1.1.http: Flags [S], seq 564208067, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:37.758069 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:40.714360 IP 83.238.153.195.2107 > 192.168.1.1.http: Flags [S], seq 564208067, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:40.714374 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:41.665503 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:46.751073 IP 83.238.153.195.2107 > 192.168.1.1.http: Flags [S], seq 564208067, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:42:46.751087 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:47.665498 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:42:59.865499 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:01.265500 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:13.320382 IP 83.238.153.195.2114 > 192.168.1.1.http: Flags [S], seq 2136055006, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:13.320399 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:16.320556 IP 83.238.153.195.2114 > 192.168.1.1.http: Flags [S], seq 2136055006, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:16.320569 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:17.665498 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:22.250069 IP 83.238.153.195.2114 > 192.168.1.1.http: Flags [S], seq 2136055006, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:22.250080 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:23.665500 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:23.865501 IP 192.168.1.1.http > 83.238.153.195.2107: Flags [S.], seq 3188568660, ack 564208068, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:35.665498 IP 192.168.1.1.http > 83.238.153.195.2114: Flags [S.], seq 3754336171, ack 2136055007, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:37.903038 IP 83.238.153.195.2213 > 192.168.1.1.http: Flags [S], seq 2918118729, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:37.903054 IP 192.168.1.1.http > 83.238.153.195.2213: Flags [S.], seq 4145523337, ack 2918118730, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:40.772899 IP 83.238.153.195.2213 > 192.168.1.1.http: Flags [S], seq 2918118729, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:40.772912 IP 192.168.1.1.http > 83.238.153.195.2213: Flags [S.], seq 4145523337, ack 2918118730, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:41.865500 IP 192.168.1.1.http > 83.238.153.195.2213: Flags [S.], seq 4145523337, ack 2918118730, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:46.793057 IP 83.238.153.195.2213 > 192.168.1.1.http: Flags [S], seq 2918118729, win 65535, options [mss 1412,nop,wscale 0,nop,nop,sackOK], length 0 19:43:46.793069 IP 192.168.1.1.http > 83.238.153.195.2213: Flags [S.], seq 4145523337, ack 2918118730, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:47.865500 IP 192.168.1.1.http > 83.238.153.195.2213: Flags [S.], seq 4145523337, ack 2918118730, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:43:49.465503 IP 192.168.1.1.http > 83.238.153.195.zephyr-srv: Flags [S.], seq 2835837547, ack 1845850584, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 Anyone have some thoughts on that?

  Read the article

• TCP stops sending weirdly.

  - by Utoah

  In case to find out the cause of TCP retransmits on my Linux (RHEL, kernel 2.6.18) servers connecting to the same switch. I had a client-server pair send "Hello" to each other every 200us and captured the packets with tcpdump on the client machine. The command I used to mimic client and server are: while [ 0 ]; do echo "Hello"; usleep 200; done | nc server 18510 while [ 0 ]; do echo "Hello"; usleep 200; done | nc -l 18510 When the server machine was busy serving some other requests, the client suffered from abrupt retransmits occasionally. But the output of tcpdump seemed irrational. 16:04:58.898970 IP server.18510 > client.34533: P 4531:4537(6) ack 3204 win 123 <nop,nop,timestamp 1923778643 3452833828> 16:04:58.901797 IP client.34533 > server.18510: P 3204:3210(6) ack 4537 win 33 <nop,nop,timestamp 3452833831 1923778643> 16:04:58.901855 IP server.18510 > client.34533: P 4537:4549(12) ack 3210 win 123 <nop,nop,timestamp 1923778646 3452833831> 16:04:58.903871 IP client.34533 > server.18510: P 3210:3216(6) ack 4549 win 33 <nop,nop,timestamp 3452833833 1923778646> 16:04:58.903950 IP server.18510 > client.34533: P 4549:4555(6) ack 3216 win 123 <nop,nop,timestamp 1923778648 3452833833> 16:04:58.905796 IP client.34533 > server.18510: P 3216:3222(6) ack 4555 win 33 <nop,nop,timestamp 3452833835 1923778648> 16:04:58.905860 IP server.18510 > client.34533: P 4555:4561(6) ack 3222 win 123 <nop,nop,timestamp 1923778650 3452833835> 16:04:58.908903 IP client.34533 > server.18510: P 3222:3228(6) ack 4561 win 33 <nop,nop,timestamp 3452833838 1923778650> 16:04:58.908966 IP server.18510 > client.34533: P 4561:4567(6) ack 3228 win 123 <nop,nop,timestamp 1923778653 3452833838> 16:04:58.911855 IP client.34533 > server.18510: P 3228:3234(6) ack 4567 win 33 <nop,nop,timestamp 3452833841 1923778653> 16:04:59.112573 IP client.34533 > server.18510: P 3228:3234(6) ack 4567 win 33 <nop,nop,timestamp 3452834042 1923778653> 16:04:59.112648 IP server.18510 > client.34533: P 4567:5161(594) ack 3234 win 123 <nop,nop,timestamp 1923778857 3452834042> 16:04:59.112659 IP client.34533 > server.18510: P 3234:3672(438) ack 5161 win 35 <nop,nop,timestamp 3452834042 1923778857> 16:04:59.114427 IP server.18510 > client.34533: P 5161:5167(6) ack 3672 win 126 <nop,nop,timestamp 1923778858 3452834042> 16:04:59.114439 IP client.34533 > server.18510: P 3672:3678(6) ack 5167 win 35 <nop,nop,timestamp 3452834044 1923778858> 16:04:59.116435 IP server.18510 > client.34533: P 5167:5173(6) ack 3678 win 126 <nop,nop,timestamp 1923778860 3452834044> 16:04:59.116444 IP client.34533 > server.18510: P 3678:3684(6) ack 5173 win 35 <nop,nop,timestamp 3452834046 1923778860> Packet 3228:3234(6) from client was retransmitted due to ack timeout. What I could not understand was that the client machine did not send out any packets after the first 3228:3234(6) packets was sent. The server machine had advertised a window (scaled) large enough. The data transfer up to the retransmit was fine which meant no slow start should be in action. What can cause the client machine to stop sending until the packet timed out? BTW, I am unable to run tcpdump on the server machine.

  Read the article

• NFS issue: clients can mount shares as NFSv3 but not as NFSv4 -- or how to debug NFS?

  - by tdn

  Problem description I have a file server running Debian. On it I have a few NFS shares. When I mount the shares from a client using NFSv3 (mount.nfs 10.0.0.51:/exports/video /mnt -o vers=3,soft,intr,timeo=10), it works. However, I would like to use NFSv4 because of improved security and performance. When I try to mount an NFSv4 share on malbec the mount command just hangs and finally times out after 2 minutes. How do I make the clients mount the NFSv4 shares as NFSv4? How do I troubleshoot NFS? There is no information in the syslog on neither client nor server. What are any errors in my configuration? Facts: Server is corvina(10.0.0.51) Client is malbec(10.0.0.1) Malbec runs Ubuntu 12.04 Server runs Debian 7 wheezy Both are connected through 1 GbE LAN. Firewalls are off. rpcinfo (root@malbec) (13-07-02 21:00) (P:0 L:1) [0] ~ # rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 4000 status 100024 1 tcp 4000 status (root@malbec) (13-07-02 21:00) (P:0 L:1) [0] ~ # rpcinfo -p corvina program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 4000 status 100024 1 tcp 4000 status 100003 3 udp 2049 nfs 100227 3 udp 2049 100021 1 udp 4003 nlockmgr 100021 3 udp 4003 nlockmgr 100021 4 udp 4003 nlockmgr 100021 1 tcp 4003 nlockmgr 100021 3 tcp 4003 nlockmgr 100021 4 tcp 4003 nlockmgr 100005 1 udp 4002 mountd 100005 1 tcp 4002 mountd 100005 2 udp 4002 mountd 100005 2 tcp 4002 mountd 100005 3 udp 4002 mountd 100005 3 tcp 4002 mountd tcpdump The following is output from tcpdump on malbec while running this command: # rpcinfo -p corvina ~ # tcpdump -i eth0 host 10.0.0.51 21:14:51.762083 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [S], seq 3069120722, win 14600, options [mss 1460,sackOK,TS val 146111 ecr 0,nop,wscale 7], length 0 21:14:51.762431 IP corvina.vineyard.sikkerhed.org.sunrpc > malbec.vineyard.sikkerhed.org.948: Flags [S.], seq 770684199, ack 3069120723, win 14480, options [mss 1460,sackOK,TS val 398850 ecr 146111,nop,wscale 7], length 0 21:14:51.762458 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [.], ack 1, win 115, options [nop,nop,TS val 146111 ecr 398850], length 0 21:14:51.762556 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [P.], seq 1:45, ack 1, win 115, options [nop,nop,TS val 146111 ecr 398850], length 44 21:14:51.762710 IP corvina.vineyard.sikkerhed.org.sunrpc > malbec.vineyard.sikkerhed.org.948: Flags [.], ack 45, win 114, options [nop,nop,TS val 398850 ecr 146111], length 0 21:14:51.763282 IP corvina.vineyard.sikkerhed.org.sunrpc > malbec.vineyard.sikkerhed.org.948: Flags [P.], seq 1:473, ack 45, win 114, options [nop,nop,TS val 398850 ecr 146111], length 472 21:14:51.763302 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [.], ack 473, win 123, options [nop,nop,TS val 146111 ecr 398850], length 0 21:14:51.764059 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [F.], seq 45, ack 473, win 123, options [nop,nop,TS val 146111 ecr 398850], length 0 21:14:51.764454 IP corvina.vineyard.sikkerhed.org.sunrpc > malbec.vineyard.sikkerhed.org.948: Flags [F.], seq 473, ack 46, win 114, options [nop,nop,TS val 398850 ecr 146111], length 0 21:14:51.764478 IP malbec.vineyard.sikkerhed.org.948 > corvina.vineyard.sikkerhed.org.sunrpc: Flags [.], ack 474, win 123, options [nop,nop,TS val 146111 ecr 398850], length 0 The following is output from tcpdump on malbec while runing this command: ~ # time mount.nfs4 10.0.0.51:/ /mnt -o soft,intr,timeo=10 21:14:58.397327 IP malbec.vineyard.sikkerhed.org.872 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1298959870, win 14600, options [mss 1460,sackOK,TS val 147769 ecr 0,nop,wscale 7], length 0 21:14:58.397655 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.872: Flags [R.], seq 0, ack 1298959871, win 0, length 0 21:14:59.470270 IP malbec.vineyard.sikkerhed.org.854 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 4111013041, win 14600, options [mss 1460,sackOK,TS val 148038 ecr 0,nop,wscale 7], length 0 21:14:59.470569 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.854: Flags [R.], seq 0, ack 4111013042, win 0, length 0 21:15:01.506179 IP malbec.vineyard.sikkerhed.org.988 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1642454567, win 14600, options [mss 1460,sackOK,TS val 148547 ecr 0,nop,wscale 7], length 0 21:15:01.506514 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.988: Flags [R.], seq 0, ack 1642454568, win 0, length 0 21:15:05.542216 IP malbec.vineyard.sikkerhed.org.882 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 3844460520, win 14600, options [mss 1460,sackOK,TS val 149556 ecr 0,nop,wscale 7], length 0 21:15:05.542484 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.882: Flags [R.], seq 0, ack 3844460521, win 0, length 0 21:15:13.602228 IP malbec.vineyard.sikkerhed.org.969 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1317773588, win 14600, options [mss 1460,sackOK,TS val 151571 ecr 0,nop,wscale 7], length 0 21:15:13.602527 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.969: Flags [R.], seq 0, ack 1317773589, win 0, length 0 21:15:18.615027 ARP, Request who-has malbec.vineyard.sikkerhed.org tell corvina.vineyard.sikkerhed.org, length 46 21:15:18.615048 ARP, Reply malbec.vineyard.sikkerhed.org is-at cc:52:af:46:af:23 (oui Unknown), length 28 21:15:23.622223 IP malbec.vineyard.sikkerhed.org.1003 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 2896563167, win 14600, options [mss 1460,sackOK,TS val 154076 ecr 0,nop,wscale 7], length 0 21:15:23.622557 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.1003: Flags [R.], seq 0, ack 2896563168, win 0, length 0 21:15:28.629913 ARP, Request who-has corvina.vineyard.sikkerhed.org tell malbec.vineyard.sikkerhed.org, length 28 21:15:28.630223 ARP, Reply corvina.vineyard.sikkerhed.org is-at 00:9c:02:ab:db:54 (oui Unknown), length 46 21:15:33.662200 IP malbec.vineyard.sikkerhed.org.727 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1334644196, win 14600, options [mss 1460,sackOK,TS val 156586 ecr 0,nop,wscale 7], length 0 21:15:33.663657 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.727: Flags [R.], seq 0, ack 1334644197, win 0, length 0 21:15:43.698207 IP malbec.vineyard.sikkerhed.org.rsync > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 688828331, win 14600, options [mss 1460,sackOK,TS val 159095 ecr 0,nop,wscale 7], length 0 21:15:43.698541 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.rsync: Flags [R.], seq 0, ack 688828332, win 0, length 0 21:15:48.707710 ARP, Request who-has malbec.vineyard.sikkerhed.org tell corvina.vineyard.sikkerhed.org, length 46 21:15:48.707726 ARP, Reply malbec.vineyard.sikkerhed.org is-at cc:52:af:46:af:23 (oui Unknown), length 28 21:15:53.738188 IP malbec.vineyard.sikkerhed.org.946 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 2021272456, win 14600, options [mss 1460,sackOK,TS val 161605 ecr 0,nop,wscale 7], length 0 21:15:53.738519 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.946: Flags [R.], seq 0, ack 2021272457, win 0, length 0 21:16:03.806216 IP malbec.vineyard.sikkerhed.org.902 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 3889059201, win 14600, options [mss 1460,sackOK,TS val 164122 ecr 0,nop,wscale 7], length 0 21:16:03.806546 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.902: Flags [R.], seq 0, ack 3889059202, win 0, length 0 21:16:08.821900 ARP, Request who-has corvina.vineyard.sikkerhed.org tell malbec.vineyard.sikkerhed.org, length 28 21:16:08.822172 ARP, Reply corvina.vineyard.sikkerhed.org is-at 00:9c:02:ab:db:54 (oui Unknown), length 46 21:16:13.874209 IP malbec.vineyard.sikkerhed.org.712 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1480927452, win 14600, options [mss 1460,sackOK,TS val 166639 ecr 0,nop,wscale 7], length 0 21:16:13.874553 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.712: Flags [R.], seq 0, ack 1961062188, win 0, length 0 21:16:18.880588 ARP, Request who-has malbec.vineyard.sikkerhed.org tell corvina.vineyard.sikkerhed.org, length 46 21:16:18.880605 ARP, Reply malbec.vineyard.sikkerhed.org is-at cc:52:af:46:af:23 (oui Unknown), length 28 21:16:23.910209 IP malbec.vineyard.sikkerhed.org.758 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1375860626, win 14600, options [mss 1460,sackOK,TS val 169148 ecr 0,nop,wscale 7], length 0 21:16:23.910532 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.758: Flags [R.], seq 0, ack 1375860627, win 0, length 0 21:16:33.982258 IP malbec.vineyard.sikkerhed.org.694 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 1769203987, win 14600, options [mss 1460,sackOK,TS val 171666 ecr 0,nop,wscale 7], length 0 21:16:33.982579 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.694: Flags [R.], seq 0, ack 1769203988, win 0, length 0 21:16:44.026241 IP malbec.vineyard.sikkerhed.org.841 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 530553783, win 14600, options [mss 1460,sackOK,TS val 174177 ecr 0,nop,wscale 7], length 0 21:16:44.026505 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.841: Flags [R.], seq 0, ack 530553784, win 0, length 0 21:16:46.213388 IP malbec.vineyard.sikkerhed.org.43460 > corvina.vineyard.sikkerhed.org.ssh: Flags [P.], seq 64:128, ack 33, win 325, options [nop,nop,TS val 174723 ecr 397437], length 64 21:16:46.213859 IP corvina.vineyard.sikkerhed.org.ssh > malbec.vineyard.sikkerhed.org.43460: Flags [P.], seq 33:65, ack 128, win 199, options [nop,nop,TS val 427466 ecr 174723], length 32 21:16:46.213883 IP malbec.vineyard.sikkerhed.org.43460 > corvina.vineyard.sikkerhed.org.ssh: Flags [.], ack 65, win 325, options [nop,nop,TS val 174723 ecr 427466], length 0 21:16:54.094242 IP malbec.vineyard.sikkerhed.org.kerberos-master > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 2673083337, win 14600, options [mss 1460,sackOK,TS val 176694 ecr 0,nop,wscale 7], length 0 21:16:54.094568 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.kerberos-master: Flags [R.], seq 0, ack 2673083338, win 0, length 0 21:17:04.134227 IP malbec.vineyard.sikkerhed.org.1019 > corvina.vineyard.sikkerhed.org.nfs: Flags [S], seq 2176607713, win 14600, options [mss 1460,sackOK,TS val 179204 ecr 0,nop,wscale 7], length 0 21:17:04.134566 IP corvina.vineyard.sikkerhed.org.nfs > malbec.vineyard.sikkerhed.org.1019: Flags [R.], seq 0, ack 2176607714, win 0, length 0 21:18:46.314021 IP malbec.vineyard.sikkerhed.org.43460 > corvina.vineyard.sikkerhed.org.ssh: Flags [P.], seq 128:192, ack 65, win 325, options [nop,nop,TS val 204749 ecr 427466], length 64 21:18:46.314462 IP corvina.vineyard.sikkerhed.org.ssh > malbec.vineyard.sikkerhed.org.43460: Flags [P.], seq 65:97, ack 192, win 199, options [nop,nop,TS val 457494 ecr 204749], length 32 21:18:46.314482 IP malbec.vineyard.sikkerhed.org.43460 > corvina.vineyard.sikkerhed.org.ssh: Flags [.], ack 97, win 325, options [nop,nop,TS val 204749 ecr 457494], length 0 21:18:51.317908 ARP, Request who-has corvina.vineyard.sikkerhed.org tell malbec.vineyard.sikkerhed.org, length 28 21:18:51.318177 ARP, Reply corvina.vineyard.sikkerhed.org is-at 00:9c:02:ab:db:54 (oui Unknown), length 46 mount command outputs mount.nfs4: Connection timed out mount.nfs4 10.0.0.51:/ /mnt -o soft,intr,timeo=10 0,00s user 0,00s system 0% cpu 2:05,80 total Returncode is 32 Server configuration I have enabled idmapd by adding NEED_IDMAPD=yes in /etc/default/nfs-common. Bind mounts in /etc/fstab: # nfs-audio /data/audio /exports/audio none bind 0 0 # nfs-clear /data/clear /exports/clear none bind 0 0 # nfs-video /data/video /exports/video none bind 0 0 /etc/exports: /exports 10.0.0.0/255.255.255.0(rw,no_root_squash,no_subtree_check,fsid=0,crossmnt) /exports/video 10.0.0.0/255.255.255.0(rw,no_root_squash,no_subtree_check,crossmnt) Output from # ls -al /exports total 20 drwxr-xr-x 5 root root 4096 Jul 2 14:14 ./ drwxr-xr-x 28 root root 4096 Jul 2 13:46 ../ drwxr-xr-x 7 tdn audio 4096 Jun 7 11:30 audio/ drwxr-xr-x 11 root root 4096 Jun 29 12:07 clear/ drwxrwx--- 12 tdn video 4096 Jun 7 09:46 video/

  Read the article

• SSH not working over IPSec tunnel (Strongswan)

  - by PattPatel

  I configured a small network on a cloud virtual machine. This virtual machine has a static IP address assigned to eth0 interface that I'll call $EXTIP. mydomain.com points to $EXTIP. Inside, I have some linux containers, that get their ip through DHCP in the Subnet 10.0.0.0/24 (i called the virtual interface nat ). They run some services that can be reached through DNAT. Then I wanted to connect to these containers through an IPSec tunnel, so I configured StrongSwan. ipsec.conf: conn %default dpdaction=none rekey=no conn remote keyexchange=ikev2 ike=######## left=[$EXTIP] leftsubnet=10.0.1.0/24,10.0.0.0/24 leftauth=pubkey lefthostaccess=yes leftcert=########.pem leftfirewall=yes leftid="#########" right=%any rightsourceip=10.0.1.0/24 rightauth=######## rightid=%any rightsendcert=never eap_identity=%any auto=add type=tunnel Everything works fine, IPSec clients get IPs of the 10.0.1.0/24 subnet and can reach the containers subnet. My problem is that I'm not able to get SSH connections over the tunnel. It simply does not work, ssh client does not produce any output. Sniffing with tcpdump gives: tcpdump: 09:50:29.648206 ARP, Request who-has 10.0.0.1 tell mydomain.com, length 28 09:50:29.648246 ARP, Reply 10.0.0.1 is-at 00:ff:aa:00:00:01 (oui Unknown), length 28 09:50:29.648253 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [S], seq 4007849772, win 29200, options [mss 1460,sackOK,TS val 1151153 ecr 0,nop,wscale 7], length 0 09:50:29.648296 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [S.], seq 2809522632, ack 4007849773, win 14480, options [mss 1460,sackOK,TS val 11482992 ecr 1151153,nop,wscale 6], length 0 09:50:29.677225 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 2809522633, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 0 09:50:29.679370 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 0:23, ack 1, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 23 09:50:29.679403 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483002 ecr 1151162], length 0 09:50:29.684337 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1:32, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 31 09:50:29.685471 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1448 09:50:29.685519 IP mydomain.com > 10.0.0.1: ICMP mydomain.com unreachable - need to frag (mtu 1422), length 556 09:50:29.685567 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1402, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1370 09:50:29.685572 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 1402:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 78 09:50:29.714601 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 32, win 229, options [nop,nop,TS val 1151173 ecr 11483003], length 0 09:50:29.714642 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483012 ecr 1151173], length 120 09:50:29.723649 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 1393:1959, ack 32, win 229, options [nop,nop,TS val 1151174 ecr 11483003], length 566 09:50:29.723677 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483015 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 0 09:50:29.725688 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1480, win 251, options [nop,nop,TS val 1151177 ecr 11483003], length 0 09:50:29.952394 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483084 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 120 09:50:29.981056 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1600, win 251, options [nop,nop,TS val 1151253 ecr 11483084,nop,nop,sack 1 {1480:1600}], length 0 If you need it this is my iptables configuration file: iptables: *filter :INPUT ACCEPT [144:9669] :FORWARD DROP [0:0] :OUTPUT ACCEPT [97:15649] :interfacce-trusted - [0:0] :porte-trusted - [0:0] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j interfacce-trusted -A FORWARD -j porte-trusted -A FORWARD -j REJECT --reject-with icmp-host-unreachable -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A interfacce-trusted -i nat -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -j ACCEPT -A porte-trusted -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -j ACCEPT COMMIT *nat :PREROUTING ACCEPT [10:600] :INPUT ACCEPT [10:600] :OUTPUT ACCEPT [4:268] :POSTROUTING ACCEPT [18:1108] -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1:443 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 8069 -j DNAT --to-destination 10.0.0.3:1234 -A POSTROUTING -s 10.0.0.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT -A POSTROUTING -s 10.0.1.0/24 -o nat -j MASQUERADE -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE COMMIT Probably I'm missing something stupid... Thanks in advance for helping :))

  Read the article

• Purpose of NOP instruction and align statement in x86 assembly

  - by alvonellos

  It has been a year or so since I last took an assembly class. In that class, we were using MASM with the Irvine libraries to make it easier to program in. After we'd gone through most of the instructions, he said that the NOP instruction essentially did nothing and not to worry about using it. Anyway, it was about midterm and he has some example code that wouldn't run properly, so he told us to add a NOP instruction and it worked fine. I asked I'm after class why and what it actually did, and he said he didn't know. Anybody know?

  Read the article

• How can I read pcap files in a friendly format?

  - by Tony

  a simple cat on the pcap file looks terrible: $cat tcp_dump.pcap ?ò????YVJ? JJ ?@@.?E<??@@ ?CA??qe?U?????h? .Ceh?YVJ?? JJ ?@@.?E<??@@ CA??qe?U?????z? .ChV?YVJ$?JJ ?@@.?E<-/@@A?CA??9????F???A&? .Ck??YVJgeJJ@@.??#3E<@3{n??9CA??P???F???<K? ??`.Ck??YVJgeBB ?@@.?E4-0@@AFCA??9????F?P????? .Ck???`?YVJ?""@@.??#3E?L@3?I??9CA??P???F????? ???.Ck?220-rly-da03.mx etc. I tried to make it prettier with: sudo tcpdump -ttttnnr tcp_dump.pcap reading from file tcp_dump.pcap, link-type EN10MB (Ethernet) 2009-07-09 20:57:40.819734 IP 67.23.28.65.49237 > 216.239.113.101.25: S 2535121895:2535121895(0) win 5840 <mss 1460,sackOK,timestamp 776168808 0,nop,wscale 5> 2009-07-09 20:57:43.819905 IP 67.23.28.65.49237 > 216.239.113.101.25: S 2535121895:2535121895(0) win 5840 <mss 1460,sackOK,timestamp 776169558 0,nop,wscale 5> 2009-07-09 20:57:47.248100 IP 67.23.28.65.42385 > 205.188.159.57.25: S 2644526720:2644526720(0) win 5840 <mss 1460,sackOK,timestamp 776170415 0,nop,wscale 5> 2009-07-09 20:57:47.288103 IP 205.188.159.57.25 > 67.23.28.65.42385: S 1358829769:1358829769(0) ack 2644526721 win 5792 <mss 1460,sackOK,timestamp 4292123488 776170415,nop,wscale 2> 2009-07-09 20:57:47.288103 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 1 win 183 <nop,nop,timestamp 776170425 4292123488> 2009-07-09 20:57:47.368107 IP 205.188.159.57.25 > 67.23.28.65.42385: P 1:481(480) ack 1 win 1448 <nop,nop,timestamp 4292123568 776170425> 2009-07-09 20:57:47.368107 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 481 win 216 <nop,nop,timestamp 776170445 4292123568> 2009-07-09 20:57:47.368107 IP 67.23.28.65.42385 > 205.188.159.57.25: P 1:18(17) ack 481 win 216 <nop,nop,timestamp 776170445 4292123568> 2009-07-09 20:57:47.404109 IP 205.188.159.57.25 > 67.23.28.65.42385: . ack 18 win 1448 <nop,nop,timestamp 4292123606 776170445> 2009-07-09 20:57:47.404109 IP 205.188.159.57.25 > 67.23.28.65.42385: P 481:536(55) ack 18 win 1448 <nop,nop,timestamp 4292123606 776170445> 2009-07-09 20:57:47.404109 IP 67.23.28.65.42385 > 205.188.159.57.25: P 18:44(26) ack 536 win 216 <nop,nop,timestamp 776170454 4292123606> 2009-07-09 20:57:47.444112 IP 205.188.159.57.25 > 67.23.28.65.42385: P 536:581(45) ack 44 win 1448 <nop,nop,timestamp 4292123644 776170454> 2009-07-09 20:57:47.484114 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 581 win 216 <nop,nop,timestamp 776170474 4292123644> 2009-07-09 20:57:47.616121 IP 67.23.28.65.42385 > 205.188.159.57.25: P 44:50(6) ack 581 win 216 <nop,nop,timestamp 776170507 4292123644> 2009-07-09 20:57:47.652123 IP 205.188.159.57.25 > 67.23.28.65.42385: P 581:589(8) ack 50 win 1448 <nop,nop,timestamp 4292123855 776170507> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: P 50:56(6) ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: F 56:56(0) ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.668124 IP 67.23.28.65.49239 > 216.239.113.101.25: S 2642380481:2642380481(0) win 5840 <mss 1460,sackOK,timestamp 776170520 0,nop,wscale 5> 2009-07-09 20:57:47.692126 IP 205.188.159.57.25 > 67.23.28.65.42385: P 589:618(29) ack 57 win 1448 <nop,nop,timestamp 4292123893 776170516> 2009-07-09 20:57:47.692126 IP 67.23.28.65.42385 > 205.188.159.57.25: R 2644526777:2644526777(0) win 0 2009-07-09 20:57:47.692126 IP 205.188.159.57.25 > 67.23.28.65.42385: F 618:618(0) ack 57 win 1448 <nop,nop,timestamp 4292123893 776170516> 2009-07-09 20:57:47.692126 IP 67.23.28.65.42385 > 205.188.159.57.25: R 2644526777:2644526777(0) win 0 Well...that is much prettier but it doesn't show the actual messages. I can actually extract more information just viewing the RAW file. What is the best ( and preferably easiest) way to just view all the contents of the pcap file? UPDATE Thanks to the responses below, I made some progress. Here is what it looks like now: tcpdump -qns 0 -A -r blah.pcap 20:57:47.368107 IP 205.188.159.57.25 > 67.23.28.65.42385: tcp 480 0x0000: 4500 0214 834c 4000 3306 f649 cdbc 9f39 [email protected] 0x0010: 4317 1c41 0019 a591 50fe 18ca 9da0 4681 C..A....P.....F. 0x0020: 8018 05a8 848f 0000 0101 080a ffd4 9bb0 ................ 0x0030: 2e43 6bb9 3232 302d 726c 792d 6461 3033 .Ck.220-rly-da03 0x0040: 2e6d 782e 616f 6c2e 636f 6d20 4553 4d54 .mx.aol.com.ESMT 0x0050: 5020 6d61 696c 5f72 656c 6179 5f69 6e2d P.mail_relay_in- 0x0060: 6461 3033 2e34 3b20 5468 752c 2030 3920 da03.4;.Thu,.09. 0x0070: 4a75 6c20 3230 3039 2031 363a 3537 3a34 Jul.2009.16:57:4 0x0080: 3720 2d30 3430 300d 0a32 3230 2d41 6d65 7.-0400..220-Ame 0x0090: 7269 6361 204f 6e6c 696e 6520 2841 4f4c rica.Online.(AOL 0x00a0: 2920 616e 6420 6974 7320 6166 6669 6c69 ).and.its.affili 0x00b0: 6174 6564 2063 6f6d 7061 6e69 6573 2064 ated.companies.d etc. This looks good, but it still makes the actual message on the right difficult to read. Is there a way to view those messages in a more friendly way? UPDATE This made it pretty: tcpick -C -yP -r tcp_dump.pcap Thanks!

  Read the article

• outgoing DNS flood targeted to non-ISP hosts

  - by radudani

  Below is the specific traffic monitored at the network perimeter and originating from a user PC on Vista platform. My question is not about the effects of the flood, but about the nature of the source of it. Is this some known infection, or just an application went out of control? a standard NOD32 scan didn't find anything, as the user told me. Thank you for any hint. 14:40:10.115876 IP 192.168.7.42.4122 > 67.228.0.181.53: S 2742536765:2742536765(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.115943 IP 192.168.7.42.4124 > 67.228.181.207.53: S 3071079888:3071079888(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116015 IP 192.168.7.42.4126 > 67.228.0.181.53: S 3445199428:3445199428(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116086 IP 192.168.7.42.4128 > 67.228.181.207.53: S 2053198691:2053198691(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116154 IP 192.168.7.42.4130 > 67.228.0.181.53: S 2841660872:2841660872(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116222 IP 192.168.7.42.4132 > 67.228.181.207.53: S 3150822465:3150822465(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116290 IP 192.168.7.42.4134 > 67.228.0.181.53: S 1692515021:1692515021(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116358 IP 192.168.7.42.4136 > 67.228.181.207.53: S 3358275919:3358275919(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116430 IP 192.168.7.42.4138 > 67.228.0.181.53: S 930184999:930184999(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116498 IP 192.168.7.42.4140 > 67.228.181.207.53: S 1504984630:1504984630(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116566 IP 192.168.7.42.4142 > 67.228.0.181.53: S 546074424:546074424(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116634 IP 192.168.7.42.4144 > 67.228.181.207.53: S 4241828590:4241828590(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116702 IP 192.168.7.42.4146 > 67.228.0.181.53: S 668634627:668634627(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.116769 IP 192.168.7.42.4148 > 67.228.181.207.53: S 3768119461:3768119461(0) win 16384 <mss 1460,nop,nop,sackOK> 14:40:10.117360 IP 192.168.7.42.4111 > 67.228.0.181.53: 12676 op8 Resp12*- [2128q][|domain] 14:40:10.117932 IP 192.168.7.42.4112 > 67.228.181.207.53: 44190 op7 NotAuth*|$ [29103q],[|domain] 14:40:10.118726 IP 192.168.7.42.4113 > 67.228.0.181.53: 49196 inv_q [b2&3=0xeea] [64081q] [28317a] [43054n] [23433au] Type63482 (Class 5889)? M-_^OS>M-JM-m^_M-i.[|domain] 14:40:10.119934 IP 192.168.7.42.4114 > 67.228.181.207.53: 48131 updateMA Resp12$ [43850q],[|domain] 14:40:10.121164 IP 192.168.7.42.4115 > 67.228.0.181.53: 46330 updateM% [b2&3=0x665b] [23691a] [998q] [32406n] [11452au][|domain] 14:40:10.121866 IP 192.168.7.42.4116 > 67.228.181.207.53: 34425 op7 YXRRSet* [39927q][|domain] 14:40:10.123107 IP 192.168.7.42.4117 > 67.228.0.181.53: 56536 notify+ [b2&3=0x27e6] [59761a] [23005q] [33341n] [29705au][|domain] 14:40:10.123961 IP 192.168.7.42.4118 > 67.228.181.207.53: 19323 stat% [b2&3=0x14bb] [32491a] [41925q] [2038n] [5857au][|domain] 14:40:10.132499 IP 192.168.7.42.4119 > 67.228.0.181.53: 50432 updateMA+ [b2&3=0x6bc2] [10733a] [9775q] [46984n] [15261au][|domain] 14:40:10.133394 IP 192.168.7.42.4120 > 67.228.181.207.53: 2171 notify Refused$ [26027q][|domain] 14:40:10.134421 IP 192.168.7.42.4121 > 67.228.0.181.53: 25802 updateM NXDomain*-$ [28641q][|domain] 14:40:10.135392 IP 192.168.7.42.4122 > 67.228.181.207.53: 2073 updateMA+ [b2&3=0x6d0b] [43177a] [54332q] [17736n] [43636au][|domain] 14:40:10.136638 IP 192.168.7.42.4123 > 67.228.0.181.53: 15346 updateD+% [b2&3=0x577a] [61686a] [19106q] [15824n] [37833au] Type28590 (Class 64856)? [|domain] 14:40:10.137265 IP 192.168.7.42.4124 > 67.228.181.207.53: 60761 update+ [b2&3=0x2b66] [43293a] [53922q] [23115n] [11349au][|domain] 14:40:10.148122 IP 192.168.7.42.4125 > 67.228.0.181.53: 3418 op3% [b2&3=0x1a92] [51107a] [60368q] [47777n] [56081au][|domain]

  Read the article

• Understanding the nop byte(s)

  - by Cole Johnson

  Ok, so I was reading through the AMD64 manuels and knowing that nop is really an xchg eax, eax, I looked at the xchg and found something interesting, that it seems a byte can be encoded into the instruction for specifying the registers (apologies I'm on my iPod): picture. So what I am wondering is how does the processor know if there is a byte after to work with or is it that that extra register has to be of type rAX causing it to actually still be the one byte 0x90

  Read the article

• Server currently under DDOS, not sure what to do

  - by Volex

  My web server is currently under a DDOS attack I believe, the messages log is full of these kind of messages: May 13 15:51:19 kernel: nf_conntrack: table full, dropping packet. May 13 15:51:19 last message repeated 9 times May 13 15:51:24 kernel: __ratelimit: 78 callbacks suppressed May 13 15:51:24 kernel: nf_conntrack: table full, dropping packet. May 13 15:52:06 kernel: possible SYN flooding on port 80. Sending cookies. and a netstat has a huge amount of the following: tcp 0 0 my.host.com:http bb176da0.virtua.com.br:4998 SYN_RECV tcp 0 0 my.host.com:http 187.0.43.109:2694 SYN_RECV tcp 0 0 my.host.com:http 109.229.4.145:1722 SYN_RECV tcp 0 0 my.host.com:http 189-84-163-244.sodobr:63267 SYN_RECV tcp 0 0 my.host.com:http bd66839d.virtua.com.br:3469 SYN_RECV tcp 0 0 my.host.com:http 69.101.56.190.dsl.int:52552 SYN_RECV tcp 0 0 my.host.com:http pc-62-230-47-190.cm.vt:2262 SYN_RECV tcp 0 0 my.host.com:http 189-84-163-244.sodobr:63418 SYN_RECV tcp 0 0 my.host.com:http pc-62-230-47-190.cm.vt:1741 SYN_RECV tcp 0 0 my.host.com:http zaq3d739320.zaq.ne.jp:2141 SYN_RECV tcp 0 0 my.host.com:http netacc-gpn-4-80-73.po:52676 SYN_RECV tcpdump shows: 7:11:08.564510 IP 187-4-1xx-4.xxx.ipd.brasiltelecom.net.br.54821 > my.host.com.http: S 999692166:999692166(0) win 65535 <mss 1452,nop,nop,sackOK> 17:11:08.566347 IP 114-44-171-67.dynamic.hinet.net.1129 > my.host.com.http: S 605369055:605369055(0) win 65535 <mss 1440,nop,nop,sackOK> 17:11:08.570210 IP 200-101-13-130.pvoce300.ipd.brasiltelecom.net.br.5590 > my.host.com.http: S 2813379182:2813379182(0) win 16384 <mss 1460,nop,nop,sackOK> 17:11:08.571290 IP dsl-189-143-30-99-dyn.prod-infinitum.com.mx.1615 > my.host.com.http: S 281542700:281542700(0) win 65535 <mss 1452,nop,nop,sackOK> 17:11:08.583847 IP dsl-189-143-30-99-dyn.prod-infinitum.com.mx.1617 > my.host.com.http: S 499413892:499413892(0) win 65535 <mss 1452,nop,nop,sackOK> 17:11:08.588680 IP 170.51.229.112.2569 > my.host.com.http: S 2195084898:2195084898(0) win 65535 <mss 1460,nop,nop,sackOK> 17:11:08.588773 IP gw2-1.211.ru.3180 > my.host.com.http: F 2315901786:2315901786(0) ack 2620913033 win 64240 17:11:08.590656 IP 200-101-13-130.pvoce300.ipd.brasiltelecom.net.br.5614 > my.host.com.http: S 2813715032:2813715032(0) win 16384 <mss 1460,nop,nop,sackOK> 17:11:08.591212 IP 203.82.82.54.15848 > my.host.com.http: S 4070423507:4070423507(0) win 16384 <mss 1400,nop,nop,sackOK> 17:11:08.591254 IP 203.82.82.54.2545 > my.host.com.http: S 1790910784:1790910784(0) win 16384 <mss 1400,nop,nop,sackOK> 17:11:08.591289 IP 203.82.82.54.28306 > my.host.com.http: S 578615626:578615626(0) win 16384 <mss 1400,nop,nop,sackOK> 17:11:08.591591 IP gw2-1.211.ru.3191 > my.host.com.http: F 2316435991:2316435991(0) ack 2634205972 win 64240 17:11:08.591790 IP 200-101-13-130.pvoce300.ipd.brasiltelecom.net.br.5593 > my.host.com.http: S 2813659017:2813659017(0) win 16384 <mss 1460,nop,nop,sackOK> 17:11:08.593691 IP gw2-1.211.ru.3203 > my.host.com.http: F 2316834420:2316834420(0) ack 2629074987 win 64240 I'm not sure what I can do to limit/mitigate this, currently no webpages are being served, any help gratefully appreciated.

  Read the article

• Lock statement vs Monitor.Enter method.

  - by Vokinneberg

  I suppose it is an interesting code example. We have a class, let's call it Test with Finalize method. In Main method here is two code blocks where i am using lock statement and Monitor.Enter call. Also i have two instances of class Test here. The experiment is pretty simple - nulling Test variable within locking block and try to collect it manually with GC.Collect method call. So, to see the Finilaze call i am calling GC.WaitForPendingFinalizers method. Everything is very simple as you can see. By defenition of lock statement it's opens by compiler to try{...}finally{..} block with Minitor.Enter call inside of try block and Monitor.Exit in finally block. I've tryed to implement try-finally block manually. I've expected the same behaviour in both cases. in case of using lock and in case of unsing Monitor.Enter. But, surprize, surprize - it is different as you can see below. public class Test : IDisposable { private string name; public Test(string name) { this.name = name; } ~Test() { Console.WriteLine(string.Format("Finalizing class name {0}.", name)); } } class Program { static void Main(string[] args) { var test1 = new Test("Test1"); var test2 = new Test("Tesst2"); lock (test1) { test1 = null; Console.WriteLine("Manual collect 1."); GC.Collect(); GC.WaitForPendingFinalizers(); Console.WriteLine("Manual collect 2."); GC.Collect(); } var lockTaken = false; System.Threading.Monitor.Enter(test2, ref lockTaken); try { test2 = null; Console.WriteLine("Manual collect 3."); GC.Collect(); GC.WaitForPendingFinalizers(); Console.WriteLine("Manual collect 4."); GC.Collect(); } finally { System.Threading.Monitor.Exit(test2); } Console.ReadLine(); } } Output of this example is Manual collect 1. Manual collect 2. Manual collect 3. Finalizing class name Test2. Manual collect 4. And null reference exception in last finally block because test2 is null reference. I've was surprised and disasembly my code into IL. So, here is IL dump of Main method. .entrypoint .maxstack 2 .locals init ( [0] class ConsoleApplication2.Test test1, [1] class ConsoleApplication2.Test test2, [2] bool lockTaken, [3] bool <>s__LockTaken0, [4] class ConsoleApplication2.Test CS$2$0000, [5] bool CS$4$0001) L_0000: nop L_0001: ldstr "Test1" L_0006: newobj instance void ConsoleApplication2.Test::.ctor(string) L_000b: stloc.0 L_000c: ldstr "Tesst2" L_0011: newobj instance void ConsoleApplication2.Test::.ctor(string) L_0016: stloc.1 L_0017: ldc.i4.0 L_0018: stloc.3 L_0019: ldloc.0 L_001a: dup L_001b: stloc.s CS$2$0000 L_001d: ldloca.s <>s__LockTaken0 L_001f: call void [mscorlib]System.Threading.Monitor::Enter(object, bool&) L_0024: nop L_0025: nop L_0026: ldnull L_0027: stloc.0 L_0028: ldstr "Manual collect." L_002d: call void [mscorlib]System.Console::WriteLine(string) L_0032: nop L_0033: call void [mscorlib]System.GC::Collect() L_0038: nop L_0039: call void [mscorlib]System.GC::WaitForPendingFinalizers() L_003e: nop L_003f: ldstr "Manual collect." L_0044: call void [mscorlib]System.Console::WriteLine(string) L_0049: nop L_004a: call void [mscorlib]System.GC::Collect() L_004f: nop L_0050: nop L_0051: leave.s L_0066 L_0053: ldloc.3 L_0054: ldc.i4.0 L_0055: ceq L_0057: stloc.s CS$4$0001 L_0059: ldloc.s CS$4$0001 L_005b: brtrue.s L_0065 L_005d: ldloc.s CS$2$0000 L_005f: call void [mscorlib]System.Threading.Monitor::Exit(object) L_0064: nop L_0065: endfinally L_0066: nop L_0067: ldc.i4.0 L_0068: stloc.2 L_0069: ldloc.1 L_006a: ldloca.s lockTaken L_006c: call void [mscorlib]System.Threading.Monitor::Enter(object, bool&) L_0071: nop L_0072: nop L_0073: ldnull L_0074: stloc.1 L_0075: ldstr "Manual collect." L_007a: call void [mscorlib]System.Console::WriteLine(string) L_007f: nop L_0080: call void [mscorlib]System.GC::Collect() L_0085: nop L_0086: call void [mscorlib]System.GC::WaitForPendingFinalizers() L_008b: nop L_008c: ldstr "Manual collect." L_0091: call void [mscorlib]System.Console::WriteLine(string) L_0096: nop L_0097: call void [mscorlib]System.GC::Collect() L_009c: nop L_009d: nop L_009e: leave.s L_00aa L_00a0: nop L_00a1: ldloc.1 L_00a2: call void [mscorlib]System.Threading.Monitor::Exit(object) L_00a7: nop L_00a8: nop L_00a9: endfinally L_00aa: nop L_00ab: call string [mscorlib]System.Console::ReadLine() L_00b0: pop L_00b1: ret .try L_0019 to L_0053 finally handler L_0053 to L_0066 .try L_0072 to L_00a0 finally handler L_00a0 to L_00aa I does not see any difference between lock statement and Monitor.Enter call. So, why i steel have a reference to the instance of test1 in case of lock, and object is not collected by GC, but in case of using Monitor.Enter it is collected and finilized?

  Read the article

• Why the server is not responding?

  - by par

  Hello! Our server occasionally refuses to serve a simple HTML page. This is happening during a relatively high number of requests. However, the processor is not heavy loaded and there are a lot of free memory. The error seems to occure 1 out of 50 requests in average, depending on the server load. I need to find the source of the problem and take the appropriate actions to eliminate it. I have a suspicion that the problem source is a huge number of incoming network packets. There are 5000 packets per second on average. Traffic - 2 MBits/sec Can this be the cause of the error? There is an interesting thing, in case the server fails to respond, the request string is not logged to access.log by Apache. The error is repeatable from several client computers. DNS is not involved, since I have accessed the server by the IP. I have profiled the problem case with tcpdump utility. These are the good and bad sessions traced by tcpdump. The request is the same in both experiments. Good - server returns response. Bad - no response, time-out error. ---- Bad ---- 12:23:36.366292 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:23:39.362394 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:23:45.365567 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,nop,sackOK> -------- ---- Good ---- 12:27:07.632229 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:27:10.620946 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:27:10.620969 IP myserver.superbservers.com.www > 123.45.67.890.63914: S 2654770980:2654770980(0) ack 3581365571 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6> 12:27:10.838747 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 1 win 4380 12:27:10.957143 IP 123.45.67.890.63914 > myserver.superbservers.com.www: P 1:213(212) ack 1 win 4380 12:27:10.957152 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 213 win 108 12:27:10.965543 IP myserver.superbservers.com.www > 123.45.67.890.63914: P 1:630(629) ack 213 win 108 12:27:10.965621 IP myserver.superbservers.com.www > 123.45.67.890.63914: F 630:630(0) ack 213 win 108 12:27:11.183540 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 631 win 4222 12:27:11.185657 IP 123.45.67.890.63914 > myserver.superbservers.com.www: F 213:213(0) ack 631 win 4222 12:27:11.185663 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 214 win 108 -------- Hoster: SuperbHosting OS: Ubuntu Server parameters: E6300 CONROE 1.86GHZ 2 X 1MB CACHE 1066 1GB DDR2 667MHZ This is a link to apache configuration file we use http://repkin5.snow.prohosting.com/apache.txt This is server-status report taken right after time-out error. http://repkin5.snow.prohosting.com/server-status.htm There are only 10 Child Servers running out of 120, so enough space for new requests. VMSTAT procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 8900 725900 8468 65684 0 0 5 18 11 33 4 3 92 1

  Read the article

• KVM Guest with NAT + Bridged networking

  - by Daniel

  I currently have a few KVM Guests on a dedicated server with bridged networking (this works) and i can successfully ping the outside ips i assign via ifconfig (in the guest). However, due to the fact i only have 5 public ipv4 ip addresses, i would like to port forward services like so: hostip:port - kvm_guest:port UPDATE I found out KVM comes with a "default" NAT interface, so added the virtual NIC to the Guest virsh configuration then configured it in the Guest, it has the ip address: 192.168.122.112 I can successfully ping 192.168.122.112 and access all ports on 192.168.122.112 from the KVM Host, so i tried to port forward like so: iptables -t nat -I PREROUTING -p tcp --dport 5222 -j DNAT --to-destination 192.168.122.112:2521 iptables -I FORWARD -m state -d 192.168.122.0/24 --state NEW,RELATED,ESTABLISHED -j ACCEPT telnet KVM_HOST_IP 5222 just hangs on "trying" telnet 192.168.122.112 2521 works [root@node1 ~]# tcpdump port 5222 tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 23:43:47.216181 IP 1.152.245.247.51183 > null.xmpp-client: Flags [S], seq 1183303931, win 65535, options [mss 1400,nop,wscale 3,nop,nop,TS val 445777813 ecr 0,sackOK,eol], length 0 23:43:48.315747 IP 1.152.245.247.51183 > null.xmpp-client: Flags [S], seq 1183303931, win 65535, options [mss 1400,nop,wscale 3,nop,nop,TS val 445778912 ecr 0,sackOK,eol], length 0 23:43:49.415606 IP 1.152.245.247.51183 > null.xmpp-client: Flags [S], seq 1183303931, win 65535, options [mss 1400,nop,wscale 3,nop,nop,TS val 445780010 ecr 0,sackOK,eol], length 0 7 packets received by filter 0 packets dropped by kernel [root@node1 ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 state NEW,RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination All help is appreciated. Thanks.

  Read the article

• Error executing child request for handler in plugin

  - by user1348351

  I'm using nop commerce open source. I wanted to show the recently add products in home page. so what I did is I activated plugin Nop JCarousel in the admin panel. But if I select "Recently view product" as a Data source type it is working fine.But if I select "recently add product" Data source type there is error coming up. it says Server Error in '/' Application. Method not found: 'Nop.Core.IPagedList`1<Nop.Core.Domain.Catalog.Product> Nop.Services.Catalog.IProductService.SearchProducts(Int32, Int32, System.Nullable`1<Boolean>, System.Nullable`1<System.Decimal>, System.Nullable`1<System.Decimal>, Int32, System.String, Boolean, Int32, System.Collections.Generic.IList`1<Int32>, Nop.Core.Domain.Catalog.ProductSortingEnum, Int32, Int32, Boolean, System.Collections.Generic.IList`1<Int32> ByRef, Boolean)'. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.MissingMethodException: Method not found: 'Nop.Core.IPagedList`1<Nop.Core.Domain.Catalog.Product> Nop.Services.Catalog.IProductService.SearchProducts(Int32, Int32, System.Nullable`1<Boolean>, System.Nullable`1<System.Decimal>, System.Nullable`1<System.Decimal>, Int32, System.String, Boolean, Int32, System.Collections.Generic.IList`1<Int32>, Nop.Core.Domain.Catalog.ProductSortingEnum, Int32, Int32, Boolean, System.Collections.Generic.IList`1<Int32> ByRef, Boolean)'. Source Error: Line 3: @foreach (var widget in Model) Line 4: { Line 5: @Html.Action(widget.ActionName, widget.ControllerName, widget.RouteValues) Line 6: } Any idea on how to solve this?

  Read the article

• csync2 ERROR: Connection to remote host failed

  - by Emil Salama

  I was unable to find any articles to answer this question, so my best bet was to post this here: Scenario We have 2x application servers in production hosting a PHP website and I would like some folders to be syncronized between the 2, the same was setup for the development environment with no issues, I've followed all instructions from the URL "http://www.cloudedify.com/synchronising-files-in-cloud-with-csync2/", I still seem to have the same result, firewall has been disabled on both boxes for troubeshooting purposes: Config Files: cysnc2.cfg nossl * *; group production { host server1; host server2; key /etc/csync-production-group.key; include /etc/httpd/sites-available; include /xxxxxx/public_html/files include /xxxxxxx/magento/media/catalog/product include /xxxxxxx/magento/media/brands exclude *.log; exclude /xxxx/public_html/file/cache; exclude /xxxxx/public_html/magento/var/cache; exclude /xxxx/public_html/logs; exclude /xxxxx/public_html/magento/var/log; backup-directory /data/sync-conflicts/; backup-generations 2; auto younger; } /etc/xinetd.d/csync2 csync2.cfg service csync2 { disable = no flags = REUSE socket_type = stream wait = no user = root group = root server = /usr/sbin/csync2 server_args = -i -D /data/sync-db/ port = 30865 type = UNLISTED log_type = FILE /data/logs/csync2/csync2-xinetd.log log_on_failure += USERID } I've made sure that the daemon is listening on both server on port 30865 and the keys matched on both servers I've run a tcpdump on each server, output as follows: 12:20:31.366771 IP server1.49919 server2.csync2: Flags [S], seq 445156159, win 14600, options [mss 1460,sackOK,TS val 794864936 ecr 0,nop,wscale 7], length 0 12:20:31.366810 IP server2.csync2 server1.49919: Flags [S.], seq 450593575, ack 445156160, win 14480, options [mss 1460,sackOK,TS val 794798911 ecr 794864936,nop,wscale 7], length 0 12:20:31.367101 IP server1.49919 server2.csync2: Flags [.], ack 1, win 115, options [nop,nop,TS val 794864937 ecr 794798911], length 0 12:20:31.367138 IP server1.49919 server2.csync2: Flags [P.], seq 1:9, ack 1, win 115, options [nop,nop,TS val 794864937 ecr 794798911], length 8 12:20:31.367147 IP server2.csync2 server1.49919: Flags [.], ack 9, win 114, options [nop,nop,TS val 794798912 ecr 794864937], length 0 12:20:31.368625 IP server2.csync2 server1.49919: Flags [R.], seq 1, ack 9, win 114, options [nop,nop,TS val 794798913 ecr 794864937], length 0 Is there anything else i'm missing or should be doing?

  Read the article

• Printf in assembler doesn't print

  - by Gaim

  Hi there, I have got a homework to hack program using buffer overflow ( with disassambling, program was written in C++, I haven't got the source code ). I have already managed it but I have a problem. I have to print some message on the screen, so I found out address of printf function, pushed address of "HACKED" and address of "%s" on the stack ( in this order ) and called that function. Called code passed well but nothing had been printed. I have tried to simulate the environment like in other place in the program but there has to be something wrong. Do you have any idea what I am doing wrong that I have no output, please? Thanks a lot EDIT: This program is running on Windows XP SP3 32b, written in C++, Intel asm there is the "hack" code CPU Disasm Address Hex dump Command Comments 0012F9A3 90 NOP ;hack begins 0012F9A4 90 NOP 0012F9A5 90 NOP 0012F9A6 89E5 MOV EBP,ESP 0012F9A8 83EC 7F SUB ESP,7F ;creating a place for working data 0012F9AB 83EC 7F SUB ESP,7F 0012F9AE 31C0 XOR EAX,EAX 0012F9B0 50 PUSH EAX 0012F9B1 50 PUSH EAX 0012F9B2 50 PUSH EAX 0012F9B3 89E8 MOV EAX,EBP 0012F9B5 83E8 09 SUB EAX,9 0012F9B8 BA 1406EDFF MOV EDX,FFED0614 ;address to jump, it is negative because there mustn't be 00 bytes 0012F9BD F7DA NOT EDX 0012F9BF FFE2 JMP EDX ;I have to jump because there are some values overwritten by the program 0012F9C1 90 NOP 0012F9C2 0090 00000000 ADD BYTE PTR DS:[EAX],DL 0012F9C8 90 NOP 0012F9C9 90 NOP 0012F9CA 90 NOP 0012F9CB 90 NOP 0012F9CC 6C INS BYTE PTR ES:[EDI],DX ; I/O command 0012F9CD 65:6E OUTS DX,BYTE PTR GS:[ESI] ; I/O command 0012F9CF 67:74 68 JE SHORT 0012FA3A ; Superfluous address size prefix 0012F9D2 2069 73 AND BYTE PTR DS:[ECX+73],CH 0012F9D5 203439 AND BYTE PTR DS:[EDI+ECX],DH 0012F9D8 34 2C XOR AL,2C 0012F9DA 2066 69 AND BYTE PTR DS:[ESI+69],AH 0012F9DD 72 73 JB SHORT 0012FA52 0012F9DF 74 20 JE SHORT 0012FA01 0012F9E1 3120 XOR DWORD PTR DS:[EAX],ESP 0012F9E3 6C INS BYTE PTR ES:[EDI],DX ; I/O command 0012F9E4 696E 65 7300909 IMUL EBP,DWORD PTR DS:[ESI+65],-6F6FFF8D 0012F9EB 90 NOP 0012F9EC 90 NOP 0012F9ED 90 NOP 0012F9EE 31DB XOR EBX,EBX ; hack continues 0012F9F0 8818 MOV BYTE PTR DS:[EAX],BL ; writing 00 behind word "HACKED" 0012F9F2 83E8 06 SUB EAX,6 0012F9F5 50 PUSH EAX ; address of "HACKED" 0012F9F6 B8 3B8CBEFF MOV EAX,FFBE8C3B 0012F9FB F7D0 NOT EAX 0012F9FD 50 PUSH EAX ; address of "%s" 0012F9FE B8 FFE4BFFF MOV EAX,FFBFE4FF 0012FA03 F7D0 NOT EAX 0012FA05 FFD0 CALL EAX ;address of printf This code is really ugly because I am new in assembler and there mustn't be null bytes because of buffer-overflow bug

  Read the article

• VB.NET CInt(Long) behaving differently in 32- and 64-bit environments

  - by LocoDelAssembly

  Hello everybody, this is my first message here. Today I had a problem converting a Long (Int64) to an Integer (Int32). The problem is that my code was always working in 32-bit environments, but when I try THE SAME executable in a 64-bit computer it crashes with a System.OverflowException exception. I've prepared this test code in VS2008 in a new project with default settings: Module Module1 Sub Main() Dim alpha As Long = -1 Dim delta As Integer Try delta = CInt(alpha And UInteger.MaxValue) Console.WriteLine("CINT OK") delta = Convert.ToInt32(alpha And UInteger.MaxValue) Console.WriteLine("Convert.ToInt32 OK") Catch ex As Exception Console.WriteLine(ex.GetType().ToString()) Finally Console.ReadLine() End Try End Sub End Module On my 32-bit setups (Windows XP SP3 32-bit and Windows 7 32-bit) it prints "CINT OK", but in the 64-bit computer (Windows 7 64-bit) that I've tested THE SAME executable it prints the exception name only. Is this behavior documented? I tried to find a reference but failed miserably. For reference I leave the MSIL code too: .method public static void Main() cil managed { .entrypoint .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) // Code size 88 (0x58) .maxstack 2 .locals init ([0] int64 alpha, [1] int32 delta, [2] class [mscorlib]System.Exception ex) IL_0000: nop IL_0001: ldc.i4.m1 IL_0002: conv.i8 IL_0003: stloc.0 IL_0004: nop .try { .try { IL_0005: ldloc.0 IL_0006: ldc.i4.m1 IL_0007: conv.u8 IL_0008: and IL_0009: conv.ovf.i4 IL_000a: stloc.1 IL_000b: ldstr "CINT OK" IL_0010: call void [mscorlib]System.Console::WriteLine(string) IL_0015: nop IL_0016: ldloc.0 IL_0017: ldc.i4.m1 IL_0018: conv.u8 IL_0019: and IL_001a: call int32 [mscorlib]System.Convert::ToInt32(int64) IL_001f: stloc.1 IL_0020: ldstr "Convert.ToInt32 OK" IL_0025: call void [mscorlib]System.Console::WriteLine(string) IL_002a: nop IL_002b: leave.s IL_0055 } // end .try catch [mscorlib]System.Exception { IL_002d: dup IL_002e: call void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.ProjectData::SetProjectError(class [mscorlib]System.Exception) IL_0033: stloc.2 IL_0034: nop IL_0035: ldloc.2 IL_0036: callvirt instance class [mscorlib]System.Type [mscorlib]System.Exception::GetType() IL_003b: callvirt instance string [mscorlib]System.Type::ToString() IL_0040: call void [mscorlib]System.Console::WriteLine(string) IL_0045: nop IL_0046: call void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.ProjectData::ClearProjectError() IL_004b: leave.s IL_0055 } // end handler } // end .try finally { IL_004d: nop IL_004e: call string [mscorlib]System.Console::ReadLine() IL_0053: pop IL_0054: endfinally } // end handler IL_0055: nop IL_0056: nop IL_0057: ret } // end of method Module1::Main I suspect that the instruction that is behaving differently is either conv.ovf.i4 or the ldc.i4.m1/conv.u8 pair. If you know what is going on here please let me know Thanks

  Read the article

• Is there a clean cut way of adding NOP records to an AFP file using Java?

  - by Jonas Dallman

  I have created an AFP file using embedded FOP Trunk. Since FOP Trunk does not support the no-operation tag directly under root I need to modify the created file to add a NOP record as the first record in the file. How does one do this?

  Read the article

• Will NKDbgPrintfW be compiled to nop in release build?

  - by Johann Gerell

  I know about and have used the macros DEBUGMSG, RETAILMSG, ERRORMSG, that all take a condition parameter. For general formatted debug output, though, I want to use ::NKDbgPrintfW directly and wonder if someone knows if it compiles to a nop in optimised release builds or if my own macro wrapper around it with #ifdef DEBUG is still needed?

  Read the article

• Linux policy routing - packets not coming back

  - by Bugsik

  i am trying to set up policy routing on my home server. My network looks like this: Host routed VPN gateway Internet link through VPN 192.168.0.35/24 ---> 192.168.0.5/24 ---> 192.168.0.1 DSL router 10.200.2.235/22 .... .... 10.200.0.1 VPN server The traffic from 192.168.0.32/27 should be and is routed through VPN. I wanted to define some routing policies to route some traffic from 192.168.0.5 through VPN as well - for start - from user with uid 2000. Policy routing is done using iptables mark target and ip rule fwmark. The problem: When connecting using user 2000 from 192.168.0.5 tcpdump shows outgoing packets, but nothing comes back. Traffic from 192.168.0.35 works fine (here I am not using fwmark but src policy). Here is my VPN gateway setup: # uname -a Linux placebo 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:49:02 UTC 2012 i686 i686 i386 GNU/Linux # iptables -V iptables v1.4.12 # ip -V ip utility, iproute2-ss111117 IPtables rules (all policies in table filter are ACCEPT) # iptables -t mangle -nvL Chain PREROUTING (policy ACCEPT 770K packets, 314M bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 767K packets, 312M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 5520 packets, 1920K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 782K packets, 901M bytes) pkts bytes target prot opt in out source destination 74 4707 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 2000 MARK set 0x3 Chain POSTROUTING (policy ACCEPT 788K packets, 903M bytes) pkts bytes target prot opt in out source destination # iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 996 packets, 51172 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 7 packets, 432 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1364 packets, 112K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 2302 packets, 160K bytes) pkts bytes target prot opt in out source destination 119 7588 MASQUERADE all -- * vpn 0.0.0.0/0 0.0.0.0/0 Routing: # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lan state UNKNOWN qlen 1000 link/ether 00:40:63:f9:c3:8f brd ff:ff:ff:ff:ff:ff valid_lft forever preferred_lft forever 3: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:40:63:f9:c3:8f brd ff:ff:ff:ff:ff:ff inet 192.168.0.5/24 brd 192.168.0.255 scope global lan inet6 fe80::240:63ff:fef9:c38f/64 scope link valid_lft forever preferred_lft forever 4: vpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.200.2.235/22 brd 10.200.3.255 scope global vpn # ip rule show 0: from all lookup local 32764: from all fwmark 0x3 lookup VPN 32765: from 192.168.0.32/27 lookup VPN 32766: from all lookup main 32767: from all lookup default # ip route show table VPN default via 10.200.0.1 dev vpn 10.200.0.0/22 dev vpn proto kernel scope link src 10.200.2.235 192.168.0.0/24 dev lan proto kernel scope link src 192.168.0.5 # ip route show default via 192.168.0.1 dev lan metric 100 10.200.0.0/22 dev vpn proto kernel scope link src 10.200.2.235 192.168.0.0/24 dev lan proto kernel scope link src 192.168.0.5 TCP dump showing no traffic coming back when connection is made from 192.168.0.5 user 2000 # tcpdump -i vpn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vpn, link-type RAW (Raw IP), capture size 65535 bytes ### Traffic from user 2000 on 192.168.0.5 ### 10:19:05.629985 IP 10.200.2.235.37291 > 10.100-78-194.akamai.com.http: Flags [S], seq 2868799562, win 14600, options [mss 1460,sackOK,TS val 6887764 ecr 0,nop,wscale 4], length 0 10:19:21.678001 IP 10.200.2.235.37291 > 10.100-78-194.akamai.com.http: Flags [S], seq 2868799562, win 14600, options [mss 1460,sackOK,TS val 6891776 ecr 0,nop,wscale 4], length 0 ### Traffic from 192.168.0.35 ### 10:23:12.066174 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [S], seq 2294159276, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 557451322 ecr 0,sackOK,eol], length 0 10:23:12.265640 IP 10.100-78-194.akamai.com.http > 10.200.2.235.49247: Flags [S.], seq 2521908813, ack 2294159277, win 14480, options [mss 1367,sackOK,TS val 388565772 ecr 557451322,nop,wscale 1], length 0 10:23:12.276573 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [.], ack 1, win 8214, options [nop,nop,TS val 557451534 ecr 388565772], length 0 10:23:12.293030 IP 10.200.2.235.49247 > 10.100-78-194.akamai.com.http: Flags [P.], seq 1:480, ack 1, win 8214, options [nop,nop,TS val 557451552 ecr 388565772], length 479 10:23:12.574773 IP 10.100-78-194.akamai.com.http > 10.200.2.235.49247: Flags [.], ack 480, win 7776, options [nop,nop,TS val 388566081 ecr 557451552], length 0

  Read the article

• Imperative vs. LINQ Performance on WP7

  - by Bil Simser

  Jesse Liberty had a nice post presenting the concepts around imperative, LINQ and fluent programming to populate a listbox. Check out the post as it’s a great example of some foundational things every .NET programmer should know. I was more interested in what the IL code that would be generated from imperative vs. LINQ was like and what the performance numbers are and how they differ. The code at the instruction level is interesting but not surprising. The imperative example with it’s creating lists and loops weighs in at about 60 instructions. .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } 1: .method private hidebysig instance void ImperativeMethod() cil managed 2: { 3: .maxstack 3 4: .locals init ( 5: [0] class [mscorlib]System.Collections.Generic.IEnumerable`1<int32> someData, 6: [1] class [mscorlib]System.Collections.Generic.List`1<int32> inLoop, 7: [2] int32 n, 8: [3] class [mscorlib]System.Collections.Generic.IEnumerator`1<int32> CS$5$0000, 9: [4] bool CS$4$0001) 10: L_0000: nop 11: L_0001: ldc.i4.1 12: L_0002: ldc.i4.s 50 13: L_0004: call class [mscorlib]System.Collections.Generic.IEnumerable`1<int32> [System.Core]System.Linq.Enumerable::Range(int32, int32) 14: L_0009: stloc.0 15: L_000a: newobj instance void [mscorlib]System.Collections.Generic.List`1<int32>::.ctor() 16: L_000f: stloc.1 17: L_0010: nop 18: L_0011: ldloc.0 19: L_0012: callvirt instance class [mscorlib]System.Collections.Generic.IEnumerator`1<!0> [mscorlib]System.Collections.Generic.IEnumerable`1<int32>::GetEnumerator() 20: L_0017: stloc.3 21: L_0018: br.s L_003a 22: L_001a: ldloc.3 23: L_001b: callvirt instance !0 [mscorlib]System.Collections.Generic.IEnumerator`1<int32>::get_Current() 24: L_0020: stloc.2 25: L_0021: nop 26: L_0022: ldloc.2 27: L_0023: ldc.i4.5 28: L_0024: cgt 29: L_0026: ldc.i4.0 30: L_0027: ceq 31: L_0029: stloc.s CS$4$0001 32: L_002b: ldloc.s CS$4$0001 33: L_002d: brtrue.s L_0039 34: L_002f: ldloc.1 35: L_0030: ldloc.2 36: L_0031: ldloc.2 37: L_0032: mul 38: L_0033: callvirt instance void [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0) 39: L_0038: nop 40: L_0039: nop 41: L_003a: ldloc.3 42: L_003b: callvirt instance bool [mscorlib]System.Collections.IEnumerator::MoveNext() 43: L_0040: stloc.s CS$4$0001 44: L_0042: ldloc.s CS$4$0001 45: L_0044: brtrue.s L_001a 46: L_0046: leave.s L_005a 47: L_0048: ldloc.3 48: L_0049: ldnull 49: L_004a: ceq 50: L_004c: stloc.s CS$4$0001 51: L_004e: ldloc.s CS$4$0001 52: L_0050: brtrue.s L_0059 53: L_0052: ldloc.3 54: L_0053: callvirt instance void [mscorlib]System.IDisposable::Dispose() 55: L_0058: nop 56: L_0059: endfinally 57: L_005a: nop 58: L_005b: ldarg.0 59: L_005c: ldfld class [System.Windows]System.Windows.Controls.ListBox PerfTest.MainPage::LB1 60: L_0061: ldloc.1 61: L_0062: callvirt instance void [System.Windows]System.Windows.Controls.ItemsControl::set_ItemsSource(class [mscorlib]System.Collections.IEnumerable) 62: L_0067: nop 63: L_0068: ret 64: .try L_0018 to L_0048 finally handler L_0048 to L_005a 65: } 66:   67: Compare that to the IL generated for the LINQ version which has about half of the instructions and just gets the job done, no fluff. .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } 1: .method private hidebysig instance void LINQMethod() cil managed 2: { 3: .maxstack 4 4: .locals init ( 5: [0] class [mscorlib]System.Collections.Generic.IEnumerable`1<int32> someData, 6: [1] class [mscorlib]System.Collections.Generic.IEnumerable`1<int32> queryResult) 7: L_0000: nop 8: L_0001: ldc.i4.1 9: L_0002: ldc.i4.s 50 10: L_0004: call class [mscorlib]System.Collections.Generic.IEnumerable`1<int32> [System.Core]System.Linq.Enumerable::Range(int32, int32) 11: L_0009: stloc.0 12: L_000a: ldloc.0 13: L_000b: ldsfld class [System.Core]System.Func`2<int32, bool> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate6 14: L_0010: brtrue.s L_0025 15: L_0012: ldnull 16: L_0013: ldftn bool PerfTest.MainPage::<LINQProgramming>b__4(int32) 17: L_0019: newobj instance void [System.Core]System.Func`2<int32, bool>::.ctor(object, native int) 18: L_001e: stsfld class [System.Core]System.Func`2<int32, bool> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate6 19: L_0023: br.s L_0025 20: L_0025: ldsfld class [System.Core]System.Func`2<int32, bool> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate6 21: L_002a: call class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0> [System.Core]System.Linq.Enumerable::Where<int32>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>, class [System.Core]System.Func`2<!!0, bool>) 22: L_002f: ldsfld class [System.Core]System.Func`2<int32, int32> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate7 23: L_0034: brtrue.s L_0049 24: L_0036: ldnull 25: L_0037: ldftn int32 PerfTest.MainPage::<LINQProgramming>b__5(int32) 26: L_003d: newobj instance void [System.Core]System.Func`2<int32, int32>::.ctor(object, native int) 27: L_0042: stsfld class [System.Core]System.Func`2<int32, int32> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate7 28: L_0047: br.s L_0049 29: L_0049: ldsfld class [System.Core]System.Func`2<int32, int32> PerfTest.MainPage::CS$<>9__CachedAnonymousMethodDelegate7 30: L_004e: call class [mscorlib]System.Collections.Generic.IEnumerable`1<!!1> [System.Core]System.Linq.Enumerable::Select<int32, int32>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>, class [System.Core]System.Func`2<!!0, !!1>) 31: L_0053: stloc.1 32: L_0054: ldarg.0 33: L_0055: ldfld class [System.Windows]System.Windows.Controls.ListBox PerfTest.MainPage::LB2 34: L_005a: ldloc.1 35: L_005b: callvirt instance void [System.Windows]System.Windows.Controls.ItemsControl::set_ItemsSource(class [mscorlib]System.Collections.IEnumerable) 36: L_0060: nop 37: L_0061: ret 38: } Again, not surprising here but a good indicator that you should consider using LINQ where possible. In fact if you have ReSharper installed you’ll see a squiggly (technical term) in the imperative code that says “Hey Dude, I can convert this to LINQ if you want to be c00L!” (or something like that, it’s the 2010 geek version of Clippy). What about the fluent version? As Jon correctly pointed out in the comments, when you compare the IL for the LINQ code and the IL for the fluent code it’s the same. LINQ and the fluent interface are just syntactical sugar so you decide what you’re most comfortable with. At the end of the day they’re both the same. Now onto the numbers. Again I expected the imperative version to be better performing than the LINQ version (before I saw the IL that was generated). Call it womanly instinct. A gut feel. Whatever. Some of the numbers are interesting though. For Jesse’s example of 50 items, the numbers were interesting. The imperative sample clocked in at 7ms while the LINQ version completed in 4. As the number of items went up, the elapsed time didn’t necessarily climb exponentially. At 500 items they were pretty much the same and the results were similar up to about 50,000 items. After that I tried 500,000 items where the gap widened but not by much (2.2 seconds for imperative, 2.3 for LINQ). It wasn’t until I tried 5,000,000 items where things were noticeable. Imperative filled the list in 20 seconds while LINQ took 8 seconds longer (although personally I wouldn’t suggest you put 5 million items in a list unless you want your users showing up at your door with torches and pitchforks). Here’s the table with the full results. Method/Items 50 500 5,000 50,000 500,000 5,000,000 Imperative 7ms 7ms 38ms 223ms 2230ms 20974ms LINQ/Fluent 4ms 6ms 41ms 240ms 2310ms 28731ms Like I said, at the end of the day it’s not a huge difference and you really don’t want your users waiting around for 30 seconds on a mobile device filling lists. In fact if Windows Phone 7 detects you’re taking more than 10 seconds to do any one thing, it considers the app hung and shuts it down. The results here are for Windows Phone 7 but frankly they're the same for desktop and web apps so feel free to apply it generally. From a programming perspective, choose what you like. Some LINQ statements can get pretty hairy so I usually fall back with my simple mind and write it imperatively. If you really want to impress your friends, write it old school then let ReSharper do the hard work for! Happy programming!

  Read the article

• ftp connection problem, vsftp server, active mode

  - by Mark Szente

  I have a server that runs vsftpd to handle ftp connections. One of my users have a notebook with Total Commander and WinSCP installed. Both ftp clients fail right after the connection is established to the server and it tries to download the directory listing without any particular error message. The weird thing is: the notebook works perfectly ok with other ftp servers. My ftp server also works well with other clients. In fact, this user also has a pc running on the same LAN as the notebook and the pc works well with the ftp server. We use active ftp connection mode. Passive mode works well but is not an option at this point. I would post more technical details but I don't even know what this problem is related to. Anyway, below is the server side tcpdump for the failed connection attempt. There's no further communication between the client and the server after the last line of log. Thank you very much for any hint! 23:39:24.514852 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: S 1314489715:1314489715(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,sackOK> 23:39:24.514896 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: S 2633658883:2633658883(0) ack 1314489716 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 2> 23:39:24.520842 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 1 win 62500 23:39:24.523803 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 1:21(20) ack 1 win 1460 23:39:24.546858 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 1:15(14) ack 21 win 62497 23:39:24.546902 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 15 win 1460 23:39:24.547247 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 21:55(34) ack 15 win 1460 23:39:24.762806 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 55 win 62493 23:39:30.415011 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 15:28(13) ack 55 win 62493 23:39:30.454116 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 28 win 1460 23:39:31.036283 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 55:78(23) ack 28 win 1460 23:39:31.053018 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 28:34(6) ack 78 win 62490 23:39:31.053042 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 34 win 1460 23:39:31.053268 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 78:97(19) ack 34 win 1460 23:39:31.068969 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 34:40(6) ack 97 win 62488 23:39:31.069148 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 97:112(15) ack 40 win 1460 23:39:31.069179 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 112:119(7) ack 40 win 1460 23:39:31.076981 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 119 win 62485 23:39:31.077010 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 119:177(58) ack 40 win 1460 23:39:31.114979 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 40:45(5) ack 177 win 62478 23:39:31.115164 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 177:186(9) ack 45 win 1460 23:39:31.180966 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 45:53(8) ack 186 win 62476 23:39:31.181066 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 186:216(30) ack 53 win 1460 23:39:31.213065 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 53:80(27) ack 216 win 62473 23:39:31.213180 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 216:267(51) ack 80 win 1460 23:39:31.251086 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 80:86(6) ack 267 win 62466 23:39:31.251498 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054371220 0,nop,wscale 2> 23:39:31.290979 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 86 win 1460 23:39:34.251489 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054374220 0,nop,wscale 2> 23:39:40.249625 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054380220 0,nop,wscale 2> 23:39:43.695108 IP 195.70.xx.xx.21 > 62.201.xx.xx.1057: P 2280716551:2280716588(37) ack 3838413728 win 5840 23:39:52.248791 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054392220 0,nop,wscale 2> 23:40:16.245159 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054416221 0,nop,wscale 2> 23:40:29.853685 IP 195.70.xx.xx.21 > 62.201.xx.xx.1057: FP 37:51(14) ack 1 win 5840 23:40:31.241951 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 267:304(37) ack 86 win 1460 23:40:31.381708 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 304 win 62462

  Read the article

• ftp connection problem, vsftp server, active mode

  - by Mark Szente

  I have a server that runs vsftpd to handle ftp connections. One of my users have a notebook with Total Commander and WinSCP installed. Both ftp clients fail right after the connection is established to the server and it tries to download the directory listing with the following error message: Timeout detected. Could not retrieve directory listing PORT command successful. Consider using PASV. Error listing directory '/'. The weird thing is: the notebook works perfectly ok with other ftp servers. My ftp server also works well with other clients. In fact, this user also has a pc running on the same LAN as the notebook and the pc works well with the ftp server. We use PORT ftp connection mode. Passive mode works well but is not an option at this point. I would post more technical details but I don't even know what this problem is related to. Anyway, below is the server side tcpdump for the failed connection attempt. There's no further communication between the client and the server after the last line of log. Thank you very much for any hint! 23:39:24.514852 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: S 1314489715:1314489715(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,sackOK> 23:39:24.514896 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: S 2633658883:2633658883(0) ack 1314489716 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 2> 23:39:24.520842 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 1 win 62500 23:39:24.523803 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 1:21(20) ack 1 win 1460 23:39:24.546858 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 1:15(14) ack 21 win 62497 23:39:24.546902 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 15 win 1460 23:39:24.547247 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 21:55(34) ack 15 win 1460 23:39:24.762806 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 55 win 62493 23:39:30.415011 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 15:28(13) ack 55 win 62493 23:39:30.454116 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 28 win 1460 23:39:31.036283 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 55:78(23) ack 28 win 1460 23:39:31.053018 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 28:34(6) ack 78 win 62490 23:39:31.053042 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 34 win 1460 23:39:31.053268 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 78:97(19) ack 34 win 1460 23:39:31.068969 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 34:40(6) ack 97 win 62488 23:39:31.069148 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 97:112(15) ack 40 win 1460 23:39:31.069179 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 112:119(7) ack 40 win 1460 23:39:31.076981 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 119 win 62485 23:39:31.077010 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 119:177(58) ack 40 win 1460 23:39:31.114979 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 40:45(5) ack 177 win 62478 23:39:31.115164 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 177:186(9) ack 45 win 1460 23:39:31.180966 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 45:53(8) ack 186 win 62476 23:39:31.181066 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 186:216(30) ack 53 win 1460 23:39:31.213065 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 53:80(27) ack 216 win 62473 23:39:31.213180 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 216:267(51) ack 80 win 1460 23:39:31.251086 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: P 80:86(6) ack 267 win 62466 23:39:31.251498 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054371220 0,nop,wscale 2> 23:39:31.290979 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: . ack 86 win 1460 23:39:34.251489 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054374220 0,nop,wscale 2> 23:39:40.249625 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054380220 0,nop,wscale 2> 23:39:43.695108 IP 195.70.xx.xx.21 > 62.201.xx.xx.1057: P 2280716551:2280716588(37) ack 3838413728 win 5840 23:39:52.248791 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054392220 0,nop,wscale 2> 23:40:16.245159 IP 195.70.xx.xx.20 > 62.201.xx.xx.5001: S 2640780713:2640780713(0) win 5840 <mss 1460,sackOK,timestamp 2054416221 0,nop,wscale 2> 23:40:29.853685 IP 195.70.xx.xx.21 > 62.201.xx.xx.1057: FP 37:51(14) ack 1 win 5840 23:40:31.241951 IP 195.70.xx.xx.21 > 62.201.xx.xx.2241: P 267:304(37) ack 86 win 1460 23:40:31.381708 IP 62.201.xx.xx.2241 > 195.70.xx.xx.21: . ack 304 win 62462

  Read the article

• kinit gives me a Kerberos ticket, but no AFS token

  - by Tomas Lycken

  I'm trying to setup access to my university's IT environment from my laptop running Ubuntu 12.04, by (mostly) following the IT-department's guides on AFS and Kerberos. I can get AFS working well enough so that I can navigate to my home folder (located in the nada.kth.se cell of AFS), and I can get Kerberos working well enough to forward tickets and authenticate me when I connect with ssh. However, I don't seem to get any AFS tokens locally, on my machine, so I can't just go to /afs/nada.kth.se/.../folder/file.txt on my machine and edit it. I can't even stand in /afs/nada.kth.se/.../folder and run ls without getting Permission denied errors. Why doesn't kinit -f [email protected] give me an AFS token? What do I need to do to get one?

  Read the article

• Using Reflection.Emit to match existing constructor

  - by yodaj007

  First, here is the C# code and the disassembled IL: public class Program<T> { private List<T> _items; public Program(T x, [Microsoft.Scripting.ParamDictionary] Microsoft.Scripting.IAttributesCollection col) { _items = new List<T>(); _items.Add(x); } } Here is the IL of that constructor: .method public hidebysig specialname rtspecialname instance void .ctor(!T x, class [Microsoft.Scripting]Microsoft.Scripting.IAttributesCollection col) cil managed { .param [2] .custom instance void [Microsoft.Scripting]Microsoft.Scripting.ParamDictionaryAttribute::.ctor() = ( 01 00 00 00 ) // Code size 34 (0x22) .maxstack 8 IL_0000: ldarg.0 IL_0001: call instance void [mscorlib]System.Object::.ctor() IL_0006: nop IL_0007: nop IL_0008: ldarg.0 IL_0009: newobj instance void class [mscorlib]System.Collections.Generic.List`1<!T>::.ctor() IL_000e: stfld class [mscorlib]System.Collections.Generic.List`1<!0> class Foo.Program`1<!T>::_items IL_0013: ldarg.0 IL_0014: ldfld class [mscorlib]System.Collections.Generic.List`1<!0> class Foo.Program`1<!T>::_items IL_0019: ldarg.1 IL_001a: callvirt instance void class [mscorlib]System.Collections.Generic.List`1<!T>::Add(!0) IL_001f: nop IL_0020: nop IL_0021: ret } // end of method Program`1::.ctor I am trying to understand the IL code by emitting it myself. This is what I have managed to emit: .method public hidebysig specialname rtspecialname instance void .ctor(!T A_1, class [Microsoft.Scripting]Microsoft.Scripting.IAttributesCollection A_2) cil managed { // Code size 34 (0x22) .maxstack 4 IL_0000: ldarg.0 IL_0001: call instance void [mscorlib]System.Object::.ctor() IL_0006: ldarg.0 IL_0007: newobj instance void class [mscorlib]System.Collections.Generic.List`1<!T>::.ctor() IL_000c: stfld class [mscorlib]System.Collections.Generic.List`1<!0> class MyType<!T>::_items IL_0011: ldarg.0 IL_0012: ldfld class [mscorlib]System.Collections.Generic.List`1<!0> class MyType<!T>::_items IL_0017: ldarg.s A_1 IL_0019: nop IL_001a: nop IL_001b: nop IL_001c: callvirt instance void class [mscorlib]System.Collections.Generic.List`1<!T>::Add(!0) IL_0021: ret } // end of method MyType::.ctor There are a few differences that I just can't figure out. I'm really close... How do I take care of the parameter attribute (ParamDictionaryAttribute)? I can't find a 'custom' opcode. Is the .param [2] important? How do I emit that? Why is the C# code stack size 8, while my emitted version is 4? Is this important?

  Read the article

1 2 3 4 5 6 7 8  | Next Page >