Search Results

Search found 40 results on 2 pages for 'pdu'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/2 | 1 2  | Next Page >

  • APC switched rack PDU: Startup outlet state

    - by Ian Gregory
    I have an APC Switched Rack PDU powering a number of servers in a remote datacentre. After a recent power outage, I noticed that the outlets did not automatically default to the On status once power was restored. Having reviewed the Web UI, I cannot find this option. I'm not certain of the model number (it doesn't appear to be visible in the Web UI), but I think it's this one. Is it possible to configure these PDU units to automatically power outlets after a cold start?

    Read the article

  • PDU management interface has low availability - product flaw or isolated issue

    - by DeanB
    Our colocation provider has supplied us with APC AP7932 switched 0U PDUs as part of several cabinets they provide us. We have had a lot of trouble with the network management aspect of these PDUs, which I'll describe below. We are moving to cage space in the same datacenter, and plan to provide our own PDUs, so I'd like to determine which enterprise-grade PDUs have been reliable performers from a remote management perspective. Our colo-provided PDUs are configured to support management via an SSL web UI and via telnet. We updated the firmware on all of them to the current version as of NOV2011. They respond to pings reliably, and we have no reason to suspect a network layer issue. However, we experience frequent hangs, timeouts, disconnects, and general unavailability from the embedded management host in all of the PDUs. We occasionally have to restart the microcontroller on the PDU to recover from what appears to be an occasional hard fault. The outlets stay powered (thankfully), but the management aspect is so unreliable that it has become an ops liability - we can't be confident that we could get into the PDU to power cycle a host if we needed to. We have 3 PDUs that all exhibit identical behavior. There are many manufacturers of enterprise-grade 0U switched PDUs, all with comparable features. If I looked at the datasheet for our current PDUs, they would appear to be a good fit -- only with the benefit of suffering through using them do we know to avoid them. I'd like to avoid picking a PDU that looks fine on paper, but has similar reliability issues. What has been others' experience with switched PDUs? Is this level of flakiness normal?

    Read the article

  • What is the difference between a PDU and a power strip (both 120V, 15A)?

    - by rob
    I just chatted with an APC rep about upgrading the UPSes at our office. She recommended a single higher-capacity 6-outlet Smart-UPS to replace the four Back-UPS units we currently have. When I asked how she recommended plugging in all the current devices, she recommended using a APC's AP9567 PDU, but said not to use a power strip. At first she said I had to use an APC brand PDU, but after I inquired about using a Tripp-Lite PDU, she said any brand PDU would be fine. The APC PDU previously referenced looks like a standard 120V power strip with overload protection but no surge protection. Other than overload protection (which seems redundant if plugging into the UPS), is there something else I'm missing, or should any power strip (without surge protection) be fine? Edit: I didn't mention it earlier, but we don't have a proper rack--though I did still plan to mount the PDU or power strip to something. I guess I'm wondering if there's any special reason I should pay as much as $180 for the low-end APC PDU (which just looks like a power strip to me) vs. $20-$30 for a workbench power strip.

    Read the article

  • Using Y split cables to connect two servers to a single PDU receptacle

    - by sagi
    We have bought a few 30amp 208v PDUs that only have 9 receptacles. The servers we are connecting to those PDUs will not use the full 30amps (at 80%, or actually 40% since we use redundant power) so we need to find a way to connect more than 9 servers to the same 9 receptacles so we'll be not wasting capacity that we pay for. I thought about using a Y split cable like this one: http://www.cablesandkits.com/power-cord-c14-c13-splitter-cable-awg-p-515.html That will let me connect two servers to a single receptacle. Each of the individual receptacles can provide 12 amps of power and individual servers are unlikely to consume more than 3 amps at maximal load so it should provide sufficient power. The question is if there is any other reason why this may be a bad idea and if there is any other solution other than buying PDUs with more receptacles (which I don't want to do because I must use horizontal PDU on these racks and ones with more receptacles consume more U space).

    Read the article

  • Please recommend PDU SMS format code or library for .NET or C++

    - by Pavel Radzivilovsky
    I have been searching a lot for a chunk of code, or a library to format SMS messages in PDU format and had little luck. They were either huge monsters with terrific dependencies on everything way above my requirements and a very obscure interface, totally not justifying the straight-forward, although rather complex encoding. Being on the edge of creating a NIH, my question is - have encountered the same problem and how have you solved it?

    Read the article

  • Incoming SMS - redirect to server via HTTP

    - by Colin Kinsella
    Hi I am looking for a windows application which will receive SMS via a GSM modem. The application needs to forward the 'raw' PDU via HTTP Post to a page on our server. The app needs to deal receive a confirmation reciept from our server and deal with undelivered PDU strings. I would be happy for someone to quote for building this straightforward application. Thanks CKxion

    Read the article

  • How to step down voltage from 208V to 110V

    - by Eric Dennis
    I have some racks that will be fed by 208V/20A circuits. These circuits will be conditioned and battery-backed by the facility in which these racks will live. 99% of the devices in the rack will be able to support 208V input, so I plan to use these PDUs. However, there may be one or two odd devices that will need 110V input. I know that I can use a step-down transformer to provide 110V for these devices, but that seems like overkill for such a small number of devices, plus I don't want to pay extra for the UPS functionality since my power will already be battery-backed. Any suggestions for something I can use for these one-off 110V devices?

    Read the article

  • How to step down voltage from 208V to 110V

    - by Eric Dennis
    I have some racks that will be fed by 208V/20A circuits. These circuits will be conditioned and battery-backed by the facility in which these racks will live. 99% of the devices in the rack will be able to support 208V input, so I plan to use these PDUs. However, there may be one or two odd devices that will need 110V input. I know that I can use a step-down transformer to provide 110V for these devices, but that seems like overkill for such a small number of devices, plus I don't want to pay extra for the UPS functionality since my power will already be battery-backed. Any suggestions for something I can use for these one-off 110V devices?

    Read the article

  • After segment lost TCP connection never recovers

    - by mvladic
    Take a look at following trace taken with Wireshark: http://dl.dropbox.com/u/145579/trace1.pcap or http://dl.dropbox.com/u/145579/trace2.pcap I will repeat here an interesting part (from trace1.pcap): No. Time Source Destination Protocol Length Info 1850 2012-02-09 13:44:32.609 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=581704 Win=65392 Len=0 1851 2012-02-09 13:44:32.610 192.168.4.213 172.22.37.4 COTP 550 DT TPDU (0) [COTP fragment, 509 bytes] 1852 2012-02-09 13:44:32.639 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1853 2012-02-09 13:44:32.639 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=582736 Win=65392 Len=0 1854 2012-02-09 13:44:32.657 192.168.4.213 172.22.37.4 TCP 590 [TCP Previous segment lost] 62479 > iso-tsap [ACK] Seq=583232 Ack=345 Win=65191 Len=536 1855 2012-02-09 13:44:32.657 192.168.4.213 172.22.37.4 TCP 108 [TCP segment of a reassembled PDU] 1856 2012-02-09 13:44:32.657 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1853#1] iso-tsap > 62479 [ACK] Seq=345 Ack=582736 Win=65392 Len=0 1857 2012-02-09 13:44:32.657 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1853#2] iso-tsap > 62479 [ACK] Seq=345 Ack=582736 Win=65392 Len=0 1858 2012-02-09 13:44:32.675 192.168.4.213 172.22.37.4 COTP 590 [TCP Fast Retransmission] DT TPDU (0) [COTP fragment, 509 bytes] 1859 2012-02-09 13:44:32.715 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1860 2012-02-09 13:44:32.715 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=583272 Win=65392 Len=0 1861 2012-02-09 13:44:32.796 192.168.4.213 172.22.37.4 COTP 590 [TCP Retransmission] DT TPDU (0) EOT 1862 2012-02-09 13:44:32.945 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1863 2012-02-09 13:44:32.945 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=583808 Win=65392 Len=0 1864 2012-02-09 13:44:32.963 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1865 2012-02-09 13:44:32.963 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1863#1] iso-tsap > 62479 [ACK] Seq=345 Ack=583808 Win=65392 Len=0 1866 2012-02-09 13:44:32.963 192.168.4.213 172.22.37.4 TCP 576 [TCP segment of a reassembled PDU] 1867 2012-02-09 13:44:32.963 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1863#2] iso-tsap > 62479 [ACK] Seq=345 Ack=583808 Win=65392 Len=0 1868 2012-02-09 13:44:33.235 192.168.4.213 172.22.37.4 COTP 590 [TCP Retransmission] DT TPDU (0) [COTP fragment, 509 bytes] 1869 2012-02-09 13:44:33.434 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=584344 Win=65392 Len=0 1870 2012-02-09 13:44:33.447 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1871 2012-02-09 13:44:33.447 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1869#1] iso-tsap > 62479 [ACK] Seq=345 Ack=584344 Win=65392 Len=0 1872 2012-02-09 13:44:33.806 192.168.4.213 172.22.37.4 COTP 590 [TCP Retransmission] DT TPDU (0) [COTP fragment, 509 bytes] 1873 2012-02-09 13:44:34.006 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=584880 Win=65392 Len=0 1874 2012-02-09 13:44:34.018 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1875 2012-02-09 13:44:34.018 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1873#1] iso-tsap > 62479 [ACK] Seq=345 Ack=584880 Win=65392 Len=0 1876 2012-02-09 13:44:34.932 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1877 2012-02-09 13:44:35.132 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=585416 Win=65392 Len=0 1878 2012-02-09 13:44:35.144 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1879 2012-02-09 13:44:35.144 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1877#1] iso-tsap > 62479 [ACK] Seq=345 Ack=585416 Win=65392 Len=0 1880 2012-02-09 13:44:37.172 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1881 2012-02-09 13:44:37.372 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=585952 Win=65392 Len=0 1882 2012-02-09 13:44:37.385 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1883 2012-02-09 13:44:37.385 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1881#1] iso-tsap > 62479 [ACK] Seq=345 Ack=585952 Win=65392 Len=0 1884 2012-02-09 13:44:41.632 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1885 2012-02-09 13:44:41.832 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=586488 Win=65392 Len=0 1886 2012-02-09 13:44:41.844 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1887 2012-02-09 13:44:41.844 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1885#1] iso-tsap > 62479 [ACK] Seq=345 Ack=586488 Win=65392 Len=0 1888 2012-02-09 13:44:50.554 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1889 2012-02-09 13:44:50.753 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=587024 Win=65392 Len=0 1890 2012-02-09 13:44:50.766 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1891 2012-02-09 13:44:50.766 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1889#1] iso-tsap > 62479 [ACK] Seq=345 Ack=587024 Win=65392 Len=0 1892 2012-02-09 13:45:08.385 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1893 2012-02-09 13:45:08.585 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=587560 Win=65392 Len=0 1894 2012-02-09 13:45:08.598 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1895 2012-02-09 13:45:08.598 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1893#1] iso-tsap > 62479 [ACK] Seq=345 Ack=587560 Win=65392 Len=0 1896 2012-02-09 13:45:44.059 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] 1897 2012-02-09 13:45:44.259 172.22.37.4 192.168.4.213 TCP 54 iso-tsap > 62479 [ACK] Seq=345 Ack=588096 Win=65392 Len=0 1898 2012-02-09 13:45:44.272 192.168.4.213 172.22.37.4 COTP 590 DT TPDU (0) [COTP fragment, 509 bytes] 1899 2012-02-09 13:45:44.272 172.22.37.4 192.168.4.213 TCP 54 [TCP Dup ACK 1897#1] iso-tsap > 62479 [ACK] Seq=345 Ack=588096 Win=65392 Len=0 1900 2012-02-09 13:46:55.386 192.168.4.213 172.22.37.4 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU] Some background information (not much, unfortunately, as I'm responsible only for server part): Server (172.22.37.4) is Windows Server 2008 R2 and client (192.168.4.213) is Ericsson telephone exchange of whom I do not know much. Client sends a file to server using FTAM protocol. This problem happens very often. I think, either client or server is doing sliding window protocol wrong. Server sends dup ack, client retransmits lost packet, but soon after client sends packets with wrong seq. Again, Server sends dup ack, client retransmits lost packet - but, this time with longer retransmission timeout. Again, client sends packet with wrong seq. Etc... Retransmission timeout grows to circa 4 minutes and communications never recovers to normal.

    Read the article

  • ISCSI Target Ubuntu

    - by erai
    I'm trying to setup iscsitarget on Ubuntu 12.04 but I can't connect to it. On the windows machine it says Target Error. with no other output. My ietd.conf is Target iqn.2012-06.com.org:virtual_machines.lun Lun 0 Type=fileio,Path=/media/volume0/storlun0.bin When I run iscsiadm -m discovery -t st -p localhost The output is iscsiadm: Connection to Discovery Address 127.0.0.1 failed iscsiadm: Login I/O error, failed to receive a PDU iscsiadm: retrying discovery login to 127.0.0.1 iscsiadm: Connection to Discovery Address 127.0.0.1 closed iscsiadm: Login I/O error, failed to receive a PDU iscsiadm: retrying discovery login to 127.0.0.1 iscsiadm: Connection to Discovery Address 127.0.0.1 failed iscsiadm: Login I/O error, failed to receive a PDU iscsiadm: retrying discovery login to 127.0.0.1 iscsiadm: Connection to Discovery Address 127.0.0.1 failed iscsiadm: Login I/O error, failed to receive a PDU iscsiadm: retrying discovery login to 127.0.0.1 iscsiadm: Connection to Discovery Address 127.0.0.1 failed iscsiadm: Login I/O error, failed to receive a PDU iscsiadm: retrying discovery login to 127.0.0.1 iscsiadm: connection login retries (reopen_max) 5 exceeded iscsiadm: Could not perform SendTargets discovery. dmesg output: [ 3324.804665] iscsi_trgt: Removing all connections, sessions and targets [ 3325.875343] iSCSI Enterprise Target Software - version 1.4.20.3 [ 3325.875415] iscsi_trgt: Registered io type fileio [ 3325.875420] iscsi_trgt: Registered io type blockio [ 3325.875425] iscsi_trgt: Registered io type nullio

    Read the article

  • What these numbers mean in Kannel SMSC logs?

    - by Hashmi
    What does these numbers represent ? What does their mean ? 2013-06-27 10:39:42 [9446] [6] DEBUG: SMPP PDU 0x7f8364000a50 dump: 2013-06-27 10:39:42 [9446] [6] DEBUG: type_name: enquire_link 2013-06-27 10:39:42 [9446] [6] DEBUG: command_id: 21 = 0x00000015 2013-06-27 10:39:42 [9446] [6] DEBUG: command_id: 21 = 0x00000015 2013-06-27 10:39:42 [9446] [6] DEBUG: command_status: 0 = 0x00000000 2013-06-27 10:39:42 [9446] [7] DEBUG: SMPP[mvoip]: Got PDU: 2013-06-27 10:39:42 [9446] [6] DEBUG: sequence_number: 519338176 = 0x1ef478c0 2013-06-27 10:39:42 [9446] [6] DEBUG: SMPP PDU dump ends.

    Read the article

  • HAProxy + NodeJS gets stuck on TCP Retransmission

    - by sled
    I have a HAProxy + NodeJS + Rails Setup, I use the NodeJS Server for file upload purposes. The problem I'm facing is that if I'm uploading through haproxy to nodejs and a "TCP (Fast) Retransmission" occurs because of a lost packet the TX rate on the client drops to zero for about 5-10 secs and gets flooded with TCP Retransmissions. This does not occur if I upload to NodeJS directly (TCP Retransmission happens too but it doesn't get stuck with dozens of retransmission attempts). My test setup is a simple HTML4 FORM (method POST) with a single file input field. The NodeJS Server only reads the incoming data and does nothing else. I've tested this on multiple machines, networks, browsers, always the same issue. Here's a TCP Traffic Dump from the client while uploading a file: ..... TCP 1506 [TCP segment of a reassembled PDU] >> everything is uploading fine until: TCP 1506 [TCP Fast Retransmission] [TCP segment of a reassembled PDU] TCP 66 [TCP Dup ACK 7392#1] 63265 > http [ACK] Seq=4844161 Ack=1 Win=524280 Len=0 TSval=657047088 TSecr=79373730 TCP 1506 [TCP Retransmission] [TCP segment of a reassembled PDU] >> the last message is repeated about 50 times for >>5-10 secs<< (TX drops to 0 on client, RX drops to 0 on server) TCP 1506 [TCP segment of a reassembled PDU] >> upload continues until the next TCP Fast Retransmission and the same thing happens again The haproxy.conf (haproxy v1.4.18 stable) is the following: global log 127.0.0.1 local1 debug maxconn 4096 # Total Max Connections. This is dependent on ulimit nbproc 2 defaults log global mode http option httplog option tcplog frontend http-in bind *:80 timeout client 6000 acl is_websocket path_beg /node/ use_backend node_backend if is_websocket default_backend app_backend # Rails Server (via nginx+passenger) backend app_backend option httpclose option forwardfor timeout server 30000 timeout connect 4000 server app1 127.0.0.1:3000 # node.js backend node_backend reqrep ^([^\ ]*)\ /node/(.*) \1\ /\2 option httpclose option forwardfor timeout queue 5000 timeout server 6000 timeout connect 5000 server node1 127.0.0.1:3200 weight 1 maxconn 4096 Thanks for reading! :) Simon

    Read the article

  • SSL / HTTP / No Response to Curl

    - by Alex McHale
    I am trying to send commands to a SOAP service, and getting nothing in reply. The SOAP service is at a completely separate site from either server I am testing with. I have written a dummy script with the SOAP XML embedded. When I run it at my local site, on any of three machines -- OSX, Ubuntu, or CentOS 5.3 -- it completes successfully with a good response. I then sent the script to our public host at Slicehost, where I fail to get the response back from the SOAP service. It accepts the TCP socket and proceeds with the SSL handshake. I do not however receive any valid HTTP response. This is the case whether I use my script or curl on the command line. I have rewritten the script using SOAP4R, Net::HTTP and Curb. All of which work at my local site, none of which work at the Slicehost site. I have tried to assemble the CentOS box as closely to match my Slicehost server as possible. I rebuilt the Slice to be a stock CentOS 5.3 and stock CentOS 5.4 with the same results. When I look at a tcpdump of the bad sessions on Slicehost, I see my script or curl send the XML to the remote server, and nothing comes back. When I look at the tcpdump at my local site, I see the response just fine. I have entirely disabled iptables on the Slice. Does anyone have any ideas what could be causing these results? Please let me know what additional information I can furnish. Thank you! Below is a wire trace of a sample session. The IP that starts with 173 is my server while the IP that starts with 12 is the SOAP server's. No. Time Source Destination Protocol Info 1 0.000000 173.45.x.x 12.36.x.x TCP 36872 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=137633469 TSER=0 WS=6 Frame 1 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 2 0.040000 12.36.x.x 173.45.x.x TCP https > 36872 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 Frame 2 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 3 0.040000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0 Frame 3 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 4 0.050000 173.45.x.x 12.36.x.x SSLv2 Client Hello Frame 4 (156 bytes on wire, 156 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 1, Ack: 1, Len: 102 Secure Socket Layer No. Time Source Destination Protocol Info 5 0.130000 12.36.x.x 173.45.x.x TCP [TCP segment of a reassembled PDU] Frame 5 (1434 bytes on wire, 1434 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 1, Ack: 103, Len: 1380 Secure Socket Layer No. Time Source Destination Protocol Info 6 0.130000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=103 Ack=1381 Win=8280 Len=0 Frame 6 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 1381, Len: 0 No. Time Source Destination Protocol Info 7 0.130000 12.36.x.x 173.45.x.x TLSv1 Server Hello, Certificate, Server Hello Done Frame 7 (1280 bytes on wire, 1280 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 1381, Ack: 103, Len: 1226 [Reassembled TCP Segments (2606 bytes): #5(1380), #7(1226)] Secure Socket Layer No. Time Source Destination Protocol Info 8 0.130000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=103 Ack=2607 Win=11040 Len=0 Frame 8 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 2607, Len: 0 No. Time Source Destination Protocol Info 9 0.130000 173.45.x.x 12.36.x.x TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Frame 9 (236 bytes on wire, 236 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 2607, Len: 182 Secure Socket Layer No. Time Source Destination Protocol Info 10 0.190000 12.36.x.x 173.45.x.x TLSv1 Change Cipher Spec, Encrypted Handshake Message Frame 10 (97 bytes on wire, 97 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2607, Ack: 285, Len: 43 Secure Socket Layer No. Time Source Destination Protocol Info 11 0.190000 173.45.x.x 12.36.x.x TLSv1 Application Data Frame 11 (347 bytes on wire, 347 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 285, Ack: 2650, Len: 293 Secure Socket Layer No. Time Source Destination Protocol Info 12 0.190000 173.45.x.x 12.36.x.x TCP [TCP segment of a reassembled PDU] Frame 12 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 13 0.450000 12.36.x.x 173.45.x.x TCP https > 36872 [ACK] Seq=2650 Ack=578 Win=64958 Len=0 Frame 13 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2650, Ack: 578, Len: 0 No. Time Source Destination Protocol Info 14 0.450000 173.45.x.x 12.36.x.x TCP [TCP segment of a reassembled PDU] Frame 14 (206 bytes on wire, 206 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 2038, Ack: 2650, Len: 152 No. Time Source Destination Protocol Info 15 0.510000 12.36.x.x 173.45.x.x TCP [TCP Dup ACK 13#1] https > 36872 [ACK] Seq=2650 Ack=578 Win=64958 Len=0 Frame 15 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2650, Ack: 578, Len: 0 No. Time Source Destination Protocol Info 16 0.850000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 16 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 17 1.650000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 17 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 18 3.250000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 18 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 19 6.450000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 19 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer

    Read the article

  • [android] Is it possible to receive SMS message on appWidget?

    - by cappuccino
    [Android] Hi, everyone. Is it possible to receive SMS message on appWidget? I saw android sample soucrce(API Demos). In API Demos, ExampleAppWidgetProvider class extends AppWidgetProvider, not Activity. So, I guess it is impossible to regist SMS Receiver like this, rcvIncoming = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Log.i("telephony", "SMS received"); Bundle data = intent.getExtras(); if (data != null) { // SMS uses a data format known as a PDU Object pdus[] = (Object[]) data.get("pdus"); String message = "New message:\n"; String sender = null; for (Object pdu : pdus) { SmsMessage part = SmsMessage.createFromPdu((byte[])pdu); message += part.getDisplayMessageBody(); if (sender == null) { sender = part.getDisplayOriginatingAddress(); } } Log.i(sender, message); } } }; registerReceiver(rcvIncoming, new IntentFilter("android.provider.Telephony.SMS_RECEIVED")); My goal is to receive SMS message on my custom appWidget. any help would be appreciated!!

    Read the article

  • Is it possible to receive SMS message on appWidget?

    - by cappuccino
    Is it possible to receive SMS message on appWidget? I saw android sample source(API Demos). In API Demos, ExampleAppWidgetProvider class extends AppWidgetProvider, not Activity. So, I guess it is impossible to regist SMS Receiver like this, rcvIncoming = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Log.i("telephony", "SMS received"); Bundle data = intent.getExtras(); if (data != null) { // SMS uses a data format known as a PDU Object pdus[] = (Object[]) data.get("pdus"); String message = "New message:\n"; String sender = null; for (Object pdu : pdus) { SmsMessage part = SmsMessage.createFromPdu((byte[])pdu); message += part.getDisplayMessageBody(); if (sender == null) { sender = part.getDisplayOriginatingAddress(); } } Log.i(sender, message); } } }; registerReceiver(rcvIncoming, new IntentFilter("android.provider.Telephony.SMS_RECEIVED")); My goal is to receive SMS message on my custom appWidget. Any help would be appreciated!!

    Read the article

  • Windows Storage Server 2003 R2 RDP Disconnection

    - by Antitribu
    I am unable to remote desktop to our Windows Storage Server 2003 R2 machine. There are a few people about with similar issues but no answers around. Symantec End Point is installed but no network protection. Using rdesktop in Linux I receive: ERROR: send: Connection reset by peer NOT IMPLEMENTED: PDU 12 ERROR: Connection closed Where the "PDU XX" number changes on each connection. In windows using the latest mstsc I receive: The connection was lost due to a network error. Try connecting again. If the problem persists, contact your network Administrator. Any ideas?

    Read the article

  • COM port cannot be opened in asp.net

    - by Pandiya Chendur
    I following this article for sending SMS it is a winform application.. I have referenced all the Dll's to my asp.net application..... I use an aspx page to detect a mobile device connected to a PC..... But it alwys shows COM 'n' Port could not be opened..... using SMS; using GsmComm.GsmCommunication; using GsmComm.PduConverter; public partial class _Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { GsmCommMain comm = new GsmCommMain(6, 9600, 300); comm.Open(); if (!comm.IsConnected()) { Response.Write("No Phone Connected"); } else { SmsSubmitPdu pdu = new SmsSubmitPdu("test", "+919999999999", ""); CommSetting.comm.SendMessage(pdu); } } }

    Read the article

  • Problem reading hexadecimal buffer from C socket

    - by Olaseni
    I'm using the SDL_net sockets API to create a server and client. I can easily read a string buffer, but when I try to send hexadecimal data, recv gets the length, but I cannot seem to be a able to read the buffer contents. IPaddress ip; TCPsocket server,client; int bufSize = 1024; char message[bufSize]; int len; server = SDLNet_TCP_Open(&ip); client = SDLNet_TCP_Accept(server); len = SDLNet_TCP_Recv(client,message,bufSize); Here's a snippet. the buffer length "len" is set (i.e. message length) but I can't get to the data contents in the message buffer. Some sample bind_transmitter PDU data was sent by a random client to the server at that port. I can't read the PDU (SMPP).

    Read the article

  • Why Wireshark does not recognize this HTTP response?

    - by Alois Mahdal
    I have a trivial CGI script that outputs simple text content. It's written in Perl and using CGI module and it specifies only the most basic headers: print $q->header( -type => 'text/plain', -Content_length => $length, ); print $stuff; There's no apparent issue with functionality, but I'm confused about the fact that Wireshark does not recognize the HTTP response as HTTP--it's marked as TCP. Here is request and response: GET /cgi-bin/memfile/memfile.pl?mbytes=1 HTTP/1.1 Host: 10.6.130.38 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: cs,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive HTTP/1.1 200 OK Date: Thu, 05 Apr 2012 18:52:23 GMT Server: Apache/2.2.15 (Win32) mod_ssl/2.2.15 OpenSSL/0.9.8m Content-length: 1048616 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain; charset=ISO-8859-1 XXXXXXXX... And here is the packet overview (Full packet is here on pastebin) No. Time Source srcp Destination dstp Protocol Info tcp.stream abstime 5 0.112749 10.6.130.38 80 10.6.130.53 48072 TCP [TCP segment of a reassembled PDU] 0 20:52:23.228063 Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) Ethernet II, Src: Dell_97:29:ac (00:1e:4f:97:29:ac), Dst: Dell_3b:fe:70 (00:24:e8:3b:fe:70) Internet Protocol Version 4, Src: 10.6.130.38 (10.6.130.38), Dst: 10.6.130.53 (10.6.130.53) Transmission Control Protocol, Src Port: http (80), Dst Port: 48072 (48072), Seq: 1, Ack: 330, Len: 1460 Now when I see this in Wireshark: there's usual TCP handshake then the GET request shown as HTTP with preview then the next packet contains the response, but is not marked as an HTTP response--just a generic "[TCP segment of a reassembled PDU]", and is not caught by "http.response" filter. Can somebody explain why Wireshark does not recognize it? Is there something wrong with the response?

    Read the article

  • LDAP over SSL with an EFI Fiery printer

    - by austinian
    I've got a printer with a Fiery running 8e Release 2. I can authenticate users against AD using the LDAP configuration, but I can only get it to work if I don't use SSL/TLS, and only if I use SIMPLE authentication. Right now, it's authenticating using a fairly low-impact user, but it's also the only system on our network that's not using LDAPS. I can get AD info fine over LDAPS using ldp.exe from my machine, our firewall, our mail filter, our linux boxes, etc. The only problem child is the Fiery. I've added the LDAP server certificate as a trusted cert to the Fiery, but after I check the box for Secure Communication and change the port to 636, pressing Validate results in a dialog box coming up saying: LDAP Validation Failed Server Name invalid or server is unavailable. I've tried changing the server name to use just the name, the FQDN, and the IP address, and changed it to another server, just to see if it was just this AD server that was fussy with the Fiery. EDIT: removed LDP output, added packet capture analysis from wireshark: The conversation seems pretty normal to me, up to the point where the Fiery terminates the connection after the server sends back a handshake response. Maybe they messed up their TLS implementation? I'm trying support, but it's been fairly useless so far. The cert is a SHA-2 (sha256RSA) 2048-bit certificate. Also, it looks like the Fiery is specifying TLS 1.0. Looking at http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx, I'm not seeing SHA256 and TLS 1.0 combination being supported by SChannel. headdesk perhaps that's why, after the DC changes the cipher spec, the connection is terminated by the Fiery? TLS 1.1 and 1.2 are enabled on the DC. Wireshark conversation: DC: 172.17.2.22, Fiery: 172.17.2.42 No. Time Source Source Port Destination Destination Port Protocol Length Info 1 0.000000000 172.17.2.42 48633 172.17.2.22 ldaps TCP 74 48633 > ldaps [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3101761 TSecr=0 WS=4 2 0.000182000 Dell_5e:94:e3 Broadcast ARP 60 Who has 172.17.2.42? Tell 172.17.2.22 3 0.000369000 TyanComp_c9:0f:90 Dell_5e:94:e3 ARP 60 172.17.2.42 is at 00:e0:81:c9:0f:90 4 0.000370000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 74 ldaps > 48633 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=67970573 TSecr=3101761 5 0.000548000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=3101761 TSecr=67970573 6 0.001000000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 147 Client Hello 7 0.001326000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 8 0.001513000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 9 0.001515000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=1449 Win=8736 Len=0 TSval=3101761 TSecr=67970573 10 0.001516000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=2897 Win=11632 Len=0 TSval=3101761 TSecr=67970573 11 0.001732000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 12 0.001737000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 1243 Server Hello, Certificate, Certificate Request, Server Hello Done 13 0.001738000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=4345 Win=14528 Len=0 TSval=3101761 TSecr=67970573 14 0.001739000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=5522 Win=17424 Len=0 TSval=3101761 TSecr=67970573 15 0.002906000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 78 Certificate 16 0.004155000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 333 Client Key Exchange 17 0.004338000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=361 Win=66304 Len=0 TSval=67970573 TSecr=3101762 18 0.004338000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 72 Change Cipher Spec 19 0.005481000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 327 Encrypted Handshake Message 20 0.005645000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=628 Win=66048 Len=0 TSval=67970574 TSecr=3101762 21 0.010247000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 125 Change Cipher Spec, Encrypted Handshake Message 22 0.016451000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [FIN, ACK] Seq=628 Ack=5581 Win=17424 Len=0 TSval=3101765 TSecr=67970574 23 0.016630000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5581 Ack=629 Win=66048 Len=0 TSval=67970575 TSecr=3101765 24 0.016811000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 60 ldaps > 48633 [RST, ACK] Seq=5581 Ack=629 Win=0 Len=0

    Read the article

  • What is this very short power cable called?

    - by Portman
    I have a couple of networking components in my rack that take giant AC adapters ("power bricks") that don't fit neatly into my rackmount PDU. I have one "thingy" that is shown below, and I need to buy a few more. But I have no idea what I'm searching for because I don't know what the "thingy" is called. Yes, this drawing is terrible. I would ask my 4-year-old to draw it for me because she's a better artist, but she's taking a nap.

    Read the article

  • Webserver Responses Hanging

    - by drscroogemcduck
    From some networks requesting certain images on our webserver is very flakey. I've looked at tcpdumps on both sides and the server sends back part of the file and the client ACKs the TCP packet but the server never receives the ACK. The servers view: 41 19.941136 212.169.34.114 209.20.73.85 TCP 52456 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 42 19.941136 209.20.73.85 212.169.34.114 TCP http > 52456 [SYN, ACK] Seq=0 Ack=1 Win=5440 Len=0 MSS=1360 46 20.041142 212.169.34.114 209.20.73.85 TCP 52456 > http [ACK] Seq=1 Ack=1 Win=65280 Len=0 47 20.045142 212.169.34.114 209.20.73.85 HTTP GET /map/map/s+74-WBkWk0aR28Yy-YjXA== HTTP/1.1 48 20.045142 209.20.73.85 212.169.34.114 TCP http > 52456 [ACK] Seq=1 Ack=522 Win=6432 Len=0 49 20.045142 209.20.73.85 212.169.34.114 TCP [TCP segment of a reassembled PDU] (Part of the content of the image 2720 bytes. i assume it is reassembled in tcpdump and it is fragmented over the wire.) ** never receives the ACK sent in frame 282 and will eventually resend the tcp segment ** The clients view: 274 26.161773 10.0.16.67 209.20.73.85 TCP 52456 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 276 26.262867 209.20.73.85 10.0.16.67 TCP http > 52456 [SYN, ACK] Seq=0 Ack=1 Win=5440 Len=0 MSS=1360 277 26.263255 10.0.16.67 209.20.73.85 TCP 52456 > http [ACK] Seq=1 Ack=1 Win=65280 Len=0 278 26.265193 10.0.16.67 209.20.73.85 HTTP GET /map/map/s+74-WBkWk0aR28Yy-YjXA== HTTP/1.1 279 26.365562 209.20.73.85 10.0.16.67 TCP http > 52456 [ACK] Seq=1 Ack=522 Win=6432 Len=0 280 26.368002 209.20.73.85 10.0.16.67 TCP [TCP segment of a reassembled PDU] (Part of the content of the image. Only 1400 bytes.) 282 26.571380 10.0.16.67 209.20.73.85 TCP 52456 > http [ACK] Seq=522 Ack=1361 Win=65280 Len=0 The network we are having trouble with is NATd. Is there any kind of explanation for this weirdness?

    Read the article

  • error to send SMS

    - by deni
    i have a problem with that code.. i got a error when i execute CommSetting.comm.SendMessage(pdu); the error is Phone reports generic communication error or syntax error can u tell me how to solve my problem?? thx i develop with c#, VS 2008

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1 2  | Next Page >