Search Results

Search found 1705 results on 69 pages for 'syn packet'.

Page 41/69 | < Previous Page | 37 38 39 40 41 42 43 44 45 46 47 48  | Next Page >

• 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

• 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

• PPTP connection disconnect

  - by Vladimir Franciz S. Blando

  My pptp connection wont stay connected, it will disconnect in less than a minute here are some relevant log entries May 31 13:32:31 localhost NetworkManager[931]: <info> Starting VPN service 'pptp'... May 31 13:32:31 localhost NetworkManager[931]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 15216 May 31 13:32:31 localhost NetworkManager[931]: <info> VPN service 'pptp' appeared; activating connections May 31 13:32:31 localhost NetworkManager[931]: <info> VPN plugin state changed: init (1) May 31 13:32:31 localhost NetworkManager[931]: <info> VPN plugin state changed: starting (3) May 31 13:32:31 localhost NetworkManager[931]: <info> VPN connection 'Dynalabs' (Connect) reply received. May 31 13:32:31 localhost pppd[15221]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded. May 31 13:32:31 localhost pppd[15221]: pppd 2.4.5 started by root, uid 0 May 31 13:32:31 localhost pptp[15224]: nm-pptp-service-15216 log[main:pptp.c:314]: The synchronous pptp option is NOT activated May 31 13:32:31 localhost pppd[15221]: Using interface ppp0 May 31 13:32:31 localhost pppd[15221]: Connect: ppp0 <--> /dev/pts/5 May 31 13:32:31 localhost NetworkManager[931]: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0) May 31 13:32:31 localhost NetworkManager[931]: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found. May 31 13:32:32 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' May 31 13:32:32 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply May 31 13:32:32 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. May 31 13:32:33 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' May 31 13:32:34 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. May 31 13:32:34 localhost pptp[15235]: nm-pptp-service-15216 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 1536). May 31 13:32:37 localhost pppd[15221]: CHAP authentication succeeded May 31 13:32:37 localhost kernel: [54007.078553] PPP MPPE Compression module registered May 31 13:32:40 localhost pppd[15221]: MPPE 128-bit stateless compression enabled May 31 13:32:42 localhost pppd[15221]: local IP address 10.100.0.52 May 31 13:32:42 localhost pppd[15221]: remote IP address 10.100.0.1 May 31 13:32:42 localhost pppd[15221]: primary DNS address 4.2.2.1 May 31 13:32:42 localhost pppd[15221]: secondary DNS address 255.255.255.255 May 31 13:32:42 localhost NetworkManager[931]: <info> VPN connection 'Dynalabs' (IP Config Get) reply received. May 31 13:32:42 localhost NetworkManager[931]: <info> VPN Gateway: 103.28.219.2 May 31 13:32:42 localhost NetworkManager[931]: <info> Tunnel Device: ppp0 May 31 13:32:42 localhost NetworkManager[931]: <info> Internal IP4 Address: 10.100.0.52 May 31 13:32:42 localhost NetworkManager[931]: <info> Internal IP4 Prefix: 32 May 31 13:32:42 localhost NetworkManager[931]: <info> Internal IP4 Point-to-Point Address: 10.100.0.1 May 31 13:32:42 localhost NetworkManager[931]: <info> Maximum Segment Size (MSS): 0 May 31 13:32:42 localhost NetworkManager[931]: <info> Forbid Default Route: no May 31 13:32:42 localhost NetworkManager[931]: <info> Internal IP4 DNS: 4.2.2.1 May 31 13:32:42 localhost NetworkManager[931]: <info> Internal IP4 DNS: 255.255.255.255 May 31 13:32:42 localhost NetworkManager[931]: <info> DNS Domain: '(none)' May 31 13:32:43 localhost dnsmasq[2127]: exiting on receipt of SIGTERM May 31 13:32:43 localhost NetworkManager[931]: <info> DNS: starting dnsmasq... May 31 13:32:43 localhost NetworkManager[931]: <info> (ppp0): writing resolv.conf to /sbin/resolvconf May 31 13:32:43 localhost dnsmasq[15290]: error at line 2 of /var/run/nm-dns-dnsmasq.conf May 31 13:32:43 localhost dnsmasq[15290]: FAILED to start up May 31 13:32:43 localhost NetworkManager[931]: <info> VPN connection 'Dynalabs' (IP Config Get) complete. May 31 13:32:43 localhost NetworkManager[931]: <info> Policy set 'Dynalabs' (ppp0) as default for IPv4 routing and DNS. May 31 13:32:43 localhost NetworkManager[931]: <info> VPN plugin state changed: started (4) May 31 13:32:43 localhost NetworkManager[931]: <warn> dnsmasq exited with error: Configuration problem (1) May 31 13:32:43 localhost NetworkManager[931]: <info> (ppp0): writing resolv.conf to /sbin/resolvconf May 31 13:32:43 localhost dbus[872]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) May 31 13:32:43 localhost dbus[872]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' May 31 13:33:00 localhost ntpdate[15370]: step time server 91.189.94.4 offset -1.110301 sec May 31 13:33:21 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xd6d6 May 31 13:33:21 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x93aa May 31 13:33:21 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xcc83 May 31 13:33:21 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x2031 May 31 13:33:21 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x13d4 May 31 13:33:22 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x5b11 May 31 13:33:22 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x414b May 31 13:33:22 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x2f5f May 31 13:33:22 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xe9ff May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x8e20 May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x8f0 May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf166 May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x36e6 May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xdd19 May 31 13:33:23 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xda26 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xac5 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x53a5 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x507e May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x1dc5 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf87b May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x2f27 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xd10c May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x66ef May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xa294 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xb15 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x52a2 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xd863 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x8a96 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xde19 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x9763 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xb23 May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x83ca May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x964e May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xe8ae May 31 13:33:24 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf614 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x9b1 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf086 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xbff4 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x66c5 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xe42 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf295 May 31 13:33:25 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x86fe May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x3bc1 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xbaad May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x88b5 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xd7a May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x30d5 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x2d8f May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x3933 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x8d42 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x4b4 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xa205 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x7cc5 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x1b6a May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0xf004 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x21b6 May 31 13:33:26 localhost pppd[15221]: Protocol-Reject for unsupported protocol 0x51eb

  Read the article

• Can't remove burg theme packages

  - by Lassi

  Today after trying to install and remove BURG and few themes I faced an issue. Now I can't install or remove anything. Here is the output (unfortunately partly in Finnish, I couldn't change language since it also seems to depend on package listings: lassi@lassi-ubuntu:~$ sudo apt-get autoremove Luetaan pakettiluetteloita... Valmis Muodostetaan riippuvuussuhteiden puu Luetaan tilatietoja... Valmis Seuraavat paketit POISTETAAN: burg-theme-fortune burg-theme-gnome burg-theme-picchio 0 päivitetty, 0 uutta asennusta, 3 poistettavaa ja 0 päivittämätöntä. 3 ei asennettu kokonaan tai poistettiin. Toiminnon jälkeen vapautuu 7 180 k t levytilaa. Haluatko jatkaa [K/e]? k (Luetaan tietokantaa... 166462 files and directories currently installed.) Poistetaan pakettia burg-theme-fortune... sudo: update-burg: command not found dpkg: virhe käsiteltäessä burg-theme-fortune (--remove): aliprosessi installed post-removal script palautti virhetilakoodin 1 Poistetaan pakettia burg-theme-gnome... sudo: update-burg: command not found dpkg: virhe käsiteltäessä burg-theme-gnome (--remove): aliprosessi installed post-removal script palautti virhetilakoodin 1 Poistetaan pakettia burg-theme-picchio... sudo: update-burg: command not found dpkg: virhe käsiteltäessä burg-theme-picchio (--remove): aliprosessi installed post-removal script palautti virhetilakoodin 1 Käsittelyssä tapahtui liian monta virhettä: burg-theme-fortune burg-theme-gnome burg-theme-picchio E: Sub-process /usr/bin/dpkg returned an error code (1) Basically what seems to happen is this: It creates the package lists, then tries to remove packet burg-theme-fortune. This fails as update-burg command was not found. Then dpkg reports an error while processing the packet. Same goes with all 3 packages. In the end it claims that there were too many errors, and packages stay installed. I also tried installing burg as it tries to run command update-burg, but appears that it tries to delete these packages always when I try to install or remove or do anything with apt. Any ideas how I could solve this issue? Edit: Here is the output of apt-get install burg (tried installing again to get English output) lassi@lassi-ubuntu:~$ LC_ALL=C sudo apt-get install burg [sudo] password for lassi: Reading package lists... Done Building dependency tree Reading state information... Done burg is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. Need to get 0 B/6169 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? y (Reading database ... 167497 files and directories currently installed.) Preparing to replace burg-theme-fortune 0.5.0-1 (using .../burg-theme-fortune_0.5.0-1_all.deb) ... Unpacking replacement burg-theme-fortune ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: warning: subprocess old post-removal script returned error exit status 1 dpkg - trying script from the new package instead ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error processing /var/cache/apt/archives/burg-theme-fortune_0.5.0-1_all.deb (--unpack): subprocess new post-removal script returned error exit status 1 Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 1 Preparing to replace burg-theme-gnome 0.5.0-1 (using .../burg-theme-gnome_0.5.0-1_all.deb) ... Unpacking replacement burg-theme-gnome ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: warning: subprocess old post-removal script returned error exit status 1 dpkg - trying script from the new package instead ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error processing /var/cache/apt/archives/burg-theme-gnome_0.5.0-1_all.deb (--unpack): subprocess new post-removal script returned error exit status 1 Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 1 Preparing to replace burg-theme-picchio 0.5.0-1 (using .../burg-theme-picchio_0.5.0-1_all.deb) ... Unpacking replacement burg-theme-picchio ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: warning: subprocess old post-removal script returned error exit status 1 dpkg - trying script from the new package instead ... Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error processing /var/cache/apt/archives/burg-theme-picchio_0.5.0-1_all.deb (--unpack): subprocess new post-removal script returned error exit status 1 Generating burg.cfg ... /usr/sbin/burg-probe: error: cannot stat `/boot/burg/locale'. No path or device is specified. Try `/usr/sbin/burg-probe --help' for more information. dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/burg-theme-fortune_0.5.0-1_all.deb /var/cache/apt/archives/burg-theme-gnome_0.5.0-1_all.deb /var/cache/apt/archives/burg-theme-picchio_0.5.0-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) lassi@lassi-ubuntu:~$

  Read the article

• DTracing TCP congestion control

  - by user12820842

  In a previous post, I showed how we can use DTrace to probe TCP receive and send window events. TCP receive and send windows are in effect both about flow-controlling how much data can be received - the receive window reflects how much data the local TCP is prepared to receive, while the send window simply reflects the size of the receive window of the peer TCP. Both then represent flow control as imposed by the receiver. However, consider that without the sender imposing flow control, and a slow link to a peer, TCP will simply fill up it's window with sent segments. Dealing with multiple TCP implementations filling their peer TCP's receive windows in this manner, busy intermediate routers may drop some of these segments, leading to timeout and retransmission, which may again lead to drops. This is termed congestion, and TCP has multiple congestion control strategies. We can see that in this example, we need to have some way of adjusting how much data we send depending on how quickly we receive acknowledgement - if we get ACKs quickly, we can safely send more segments, but if acknowledgements come slowly, we should proceed with more caution. More generally, we need to implement flow control on the send side also. Slow Start and Congestion Avoidance From RFC2581, let's examine the relevant variables: "The congestion window (cwnd) is a sender-side limit on the amount of data the sender can transmit into the network before receiving an acknowledgment (ACK). Another state variable, the slow start threshold (ssthresh), is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission" Slow start is used to probe the network's ability to handle transmission bursts both when a connection is first created and when retransmission timers fire. The latter case is important, as the fact that we have effectively lost TCP data acts as a motivator for re-probing how much data the network can handle from the sending TCP. The congestion window (cwnd) is initialized to a relatively small value, generally a low multiple of the sending maximum segment size. When slow start kicks in, we will only send that number of bytes before waiting for acknowledgement. When acknowledgements are received, the congestion window is increased in size until cwnd reaches the slow start threshold ssthresh value. For most congestion control algorithms the window increases exponentially under slow start, assuming we receive acknowledgements. We send 1 segment, receive an ACK, increase the cwnd by 1 MSS to 2*MSS, send 2 segments, receive 2 ACKs, increase the cwnd by 2*MSS to 4*MSS, send 4 segments etc. When the congestion window exceeds the slow start threshold, congestion avoidance is used instead of slow start. During congestion avoidance, the congestion window is generally updated by one MSS for each round-trip-time as opposed to each ACK, and so cwnd growth is linear instead of exponential (we may receive multiple ACKs within a single RTT). This continues until congestion is detected. If a retransmit timer fires, congestion is assumed and the ssthresh value is reset. It is reset to a fraction of the number of bytes outstanding (unacknowledged) in the network. At the same time the congestion window is reset to a single max segment size. Thus, we initiate slow start until we start receiving acknowledgements again, at which point we can eventually flip over to congestion avoidance when cwnd ssthresh. Congestion control algorithms differ most in how they handle the other indication of congestion - duplicate ACKs. A duplicate ACK is a strong indication that data has been lost, since they often come from a receiver explicitly asking for a retransmission. In some cases, a duplicate ACK may be generated at the receiver as a result of packets arriving out-of-order, so it is sensible to wait for multiple duplicate ACKs before assuming packet loss rather than out-of-order delivery. This is termed fast retransmit (i.e. retransmit without waiting for the retransmission timer to expire). Note that on Oracle Solaris 11, the congestion control method used can be customized. See here for more details. In general, 3 or more duplicate ACKs indicate packet loss and should trigger fast retransmit . It's best not to revert to slow start in this case, as the fact that the receiver knew it was missing data suggests it has received data with a higher sequence number, so we know traffic is still flowing. Falling back to slow start would be excessive therefore, so fast recovery is used instead. Observing slow start and congestion avoidance The following script counts TCP segments sent when under slow start (cwnd ssthresh). #!/usr/sbin/dtrace -s #pragma D option quiet tcp:::connect-request / start[args[1]-cs_cid] == 0/ { start[args[1]-cs_cid] = 1; } tcp:::send / start[args[1]-cs_cid] == 1 && args[3]-tcps_cwnd tcps_cwnd_ssthresh / { @c["Slow start", args[2]-ip_daddr, args[4]-tcp_dport] = count(); } tcp:::send / start[args[1]-cs_cid] == 1 && args[3]-tcps_cwnd args[3]-tcps_cwnd_ssthresh / { @c["Congestion avoidance", args[2]-ip_daddr, args[4]-tcp_dport] = count(); } As we can see the script only works on connections initiated since it is started (using the start[] associative array with the connection ID as index to set whether it's a new connection (start[cid] = 1). From there we simply differentiate send events where cwnd ssthresh (congestion avoidance). Here's the output taken when I accessed a YouTube video (where rport is 80) and from an FTP session where I put a large file onto a remote system. # dtrace -s tcp_slow_start.d ^C ALGORITHM RADDR RPORT #SEG Slow start 10.153.125.222 20 6 Slow start 138.3.237.7 80 14 Slow start 10.153.125.222 21 18 Congestion avoidance 10.153.125.222 20 1164 We see that in the case of the YouTube video, slow start was exclusively used. Most of the segments we sent in that case were likely ACKs. Compare this case - where 14 segments were sent using slow start - to the FTP case, where only 6 segments were sent before we switched to congestion avoidance for 1164 segments. In the case of the FTP session, the FTP data on port 20 was predominantly sent with congestion avoidance in operation, while the FTP session relied exclusively on slow start. For the default congestion control algorithm - "newreno" - on Solaris 11, slow start will increase the cwnd by 1 MSS for every acknowledgement received, and by 1 MSS for each RTT in congestion avoidance mode. Different pluggable congestion control algorithms operate slightly differently. For example "highspeed" will update the slow start cwnd by the number of bytes ACKed rather than the MSS. And to finish, here's a neat oneliner to visually display the distribution of congestion window values for all TCP connections to a given remote port using a quantization. In this example, only port 80 is in use and we see the majority of cwnd values for that port are in the 4096-8191 range. # dtrace -n 'tcp:::send { @q[args[4]-tcp_dport] = quantize(args[3]-tcps_cwnd); }' dtrace: description 'tcp:::send ' matched 10 probes ^C 80 value ------------- Distribution ------------- count -1 | 0 0 |@@@@@@ 5 1 | 0 2 | 0 4 | 0 8 | 0 16 | 0 32 | 0 64 | 0 128 | 0 256 | 0 512 | 0 1024 | 0 2048 |@@@@@@@@@ 8 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 23 8192 | 0

  Read the article

• root issues in softwarecenter, synaptic and update manager

  - by user188977

  i have a notebook samsung ativ 2 and ubuntu 12.04 precise, cinnamon desktop. after logging in today my update manager, synaptic and ubuntu softwarecenter stopped working. synaptic i can only launch from terminal the others from panel.when choosing to update, nothing happens. same thing when trying to install programms from syn. or softw.center.when launching softwarec. from terminal i get: marcus@ddddddddd:~$ software-center 2013-11-10 22:30:46,206 - softwarecenter.ui.gtk3.app - INFO - setting up proxy 'None' 2013-11-10 22:30:46,217 - softwarecenter.db.database - INFO - open() database: path=None use_axi=True use_agent=True (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:34:20: Not using units is deprecated. Assuming 'px'. (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:34:22: Not using units is deprecated. Assuming 'px'. (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:56:20: Not using units is deprecated. Assuming 'px'. (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:56:22: Not using units is deprecated. Assuming 'px'. (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:60:20: Not using units is deprecated. Assuming 'px'. (software-center:4772): Gtk-WARNING **: Theme parsing error: softwarecenter.css:60:22: Not using units is deprecated. Assuming 'px'. 2013-11-10 22:30:46,977 - softwarecenter.backend.reviews - WARNING - Could not get usefulness from server, no username in config file 2013-11-10 22:30:47,320 - softwarecenter.ui.gtk3.app - INFO - show_available_packages: search_text is '', app is None. 2013-11-10 22:30:48,057 - softwarecenter.db.pkginfo_impl.aptcache - INFO - aptcache.open() 2013-11-10 22:31:00,646 - softwarecenter.fixme - WARNING - logs to the root logger: '('/usr/share/software-center/softwarecenter/utils.py', 201, 'get_title_from_html')' 2013-11-10 22:31:00,645 - root - WARNING - failed to parse: '<div style="background-color: #161513; width:1680px; height:200px;">  <div style="background: url('/site_media/exhibits/2013/09/AAMFP_Leaderboard_700x200_1.jpg') top left no-repeat; width:700px; height:200px;"></div> </div>' ('ascii' codec can't encode character u'\xa0' in position 70: ordinal not in range(128)) 2013-11-10 22:31:02,268 - softwarecenter.db.update - INFO - skipping region restricted app: 'Comentarios Web' (not whitelisted) 2013-11-10 22:31:02,769 - softwarecenter.db.update - INFO - skipping region restricted app: 'reEarCandy' (not whitelisted) 2013-11-10 22:31:04,821 - softwarecenter.db.update - INFO - skipping region restricted app: 'Flaggame' (not whitelisted) 2013-11-10 22:31:05,622 - softwarecenter.db.update - INFO - skipping region restricted app: 'Bulleti d'esquerra de Calonge i Sant Antoni ' (not whitelisted) 2013-11-10 22:31:08,352 - softwarecenter.ui.gtk3.app - INFO - software-center-agent finished with status 0 2013-11-10 22:31:08,353 - softwarecenter.db.database - INFO - reopen() database 2013-11-10 22:31:08,353 - softwarecenter.db.database - INFO - open() database: path=None use_axi=True use_agent=True 2013-11-10 22:33:32,319 - softwarecenter.backend - WARNING - _on_trans_error: org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name': ':1.72'}): org.debian.apt.install-or-remove-packages 2013-11-10 22:36:01,818 - softwarecenter.backend - WARNING - daemon dies, ignoring: <AptTransaction object at 0x48e4b40 (aptdaemon+client+AptTransaction at 0x645aaa0)> exit-failed 2013-11-10 22:36:01,820 - softwarecenter.db.pkginfo_impl.aptcache - INFO - aptcache.open()

  Read the article

• FreeBSD performance tuning. Sysctls, loader.conf, kernel

  - by SaveTheRbtz

  I wanted to share knowledge of tuning FreeBSD via sysctl.conf/loader.conf/KENCONF. It was initially based on Igor Sysoev's (author of nginx) presentation about FreeBSD tuning up to 100,000-200,000 active connections. Tunings are for FreeBSD-CURRENT. Since 7.2 amd64 some of them are tuned well by default. Prior 7.0 some of them are boot only (set via /boot/loader.conf) or does not exist at all. sysctl.conf: # No zero mapping feature # May break wine # (There are also reports about broken samba3) #security.bsd.map_at_zero=0 # If you have really busy webserver with apache13 you may run out of processes #kern.maxproc=10000 # Same for servers with apache2 / Pound #kern.threads.max_threads_per_proc=4096 # Max. backlog size kern.ipc.somaxconn=4096 # Shared memory // 7.2+ can use shared memory > 2Gb kern.ipc.shmmax=2147483648 # Sockets kern.ipc.maxsockets=204800 # Can cause this on older kernels: # http://old.nabble.com/Significant-performance-regression-for-increased-maxsockbuf-on-8.0-RELEASE-tt26745981.html#a26745981 ) kern.ipc.maxsockbuf=10485760 # Mbuf 2k clusters (on amd64 7.2+ 25600 is default) # For such high value vm.kmem_size must be increased to 3G kern.ipc.nmbclusters=262144 # Jumbo pagesize(_SC_PAGESIZE) clusters # Used as general packet storage for jumbo frames # can be monitored via `netstat -m` #kern.ipc.nmbjumbop=262144 # Jumbo 9k/16k clusters # If you are using them #kern.ipc.nmbjumbo9=65536 #kern.ipc.nmbjumbo16=32768 # For lower latency you can decrease scheduler's maximum time slice # default: stathz/10 (~ 13) #kern.sched.slice=1 # Increase max command-line length showed in `ps` (e.g for Tomcat/Java) # Default is PAGE_SIZE / 16 or 256 on x86 # This avoids commands to be presented as [executable] in `ps` # For more info see: http://www.freebsd.org/cgi/query-pr.cgi?pr=120749 kern.ps_arg_cache_limit=4096 # Every socket is a file, so increase them kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.maxvnodes=200000 # On some systems HPET is almost 2 times faster than default ACPI-fast # Useful on systems with lots of clock_gettime / gettimeofday calls # See http://old.nabble.com/ACPI-fast-default-timecounter,-but-HPET-83--faster-td23248172.html # After revision 222222 HPET became default: http://svnweb.freebsd.org/base?view=revision&revision=222222 kern.timecounter.hardware=HPET # Small receive space, only usable on http-server, on file server this # should be increased to 65535 or even more #net.inet.tcp.recvspace=8192 # This is useful on Fat-Long-Pipes #net.inet.tcp.recvbuf_max=10485760 #net.inet.tcp.recvbuf_inc=65535 # Small send space is useful for http servers that serve small files # Autotuned since 7.x net.inet.tcp.sendspace=16384 # This is useful on Fat-Long-Pipes #net.inet.tcp.sendbuf_max=10485760 #net.inet.tcp.sendbuf_inc=65535 # Turn off receive autotuning # You can play with it. #net.inet.tcp.recvbuf_auto=0 #net.inet.tcp.sendbuf_auto=0 # This should be enabled if you going to use big spaces (>64k) # Also timestamp field is useful when using syncookies net.inet.tcp.rfc1323=1 # Turn this off on high-speed, lossless connections (LAN 1Gbit+) # If you set it there is no need in TCP_NODELAY sockopt (see man tcp) net.inet.tcp.delayed_ack=0 # This feature is useful if you are serving data over modems, Gigabit Ethernet, # or even high speed WAN links (or any other link with a high bandwidth delay product), # especially if you are also using window scaling or have configured a large send window. # Automatically disables on small RTT ( http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_subr.c?#rev1.237 ) # This sysctl was removed in 10-CURRENT: # See: http://www.mail-archive.com/[email protected]/msg06178.html #net.inet.tcp.inflight.enable=0 # TCP slowstart algorithm tunings # We assuming we have very fast clients #net.inet.tcp.slowstart_flightsize=100 #net.inet.tcp.local_slowstart_flightsize=100 # Disable randomizing of ports to avoid false RST # Before usage check SA here www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf # (it's also says that port randomization auto-disables at some conn.rates, but I didn't checked it thou) #net.inet.ip.portrange.randomized=0 # Increase portrange # For outgoing connections only. Good for seed-boxes and ftp servers. net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 # # stops route cache degregation during a high-bandwidth flood # http://www.freebsd.org/doc/en/books/handbook/securing-freebsd.html #net.inet.ip.rtexpire=2 net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 # Security net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 net.inet.icmp.log_redirect=0 net.inet.icmp.drop_redirect=1 net.inet.tcp.drop_synfin=1 # # There is also good example of sysctl.conf with comments: # http://www.thern.org/projects/sysctl.conf # # icmp may NOT rst, helpful for those pesky spoofed # icmp/udp floods that end up taking up your outgoing # bandwidth/ifqueue due to all that outgoing RST traffic. # #net.inet.tcp.icmp_may_rst=0 # Security net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 # IPv6 Security # For more info see http://www.fosslc.org/drupal/content/security-implications-ipv6 # Disable Node info replies # To see this vulnerability in action run `ping6 -a sglAac ::1` or `ping6 -w ::1` on unprotected node net.inet6.icmp6.nodeinfo=0 # Turn on IPv6 privacy extensions # For more info see proposal http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00103.html net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 # Disable ICMP redirect net.inet6.icmp6.rediraccept=0 # Disable acceptation of RA and auto linklocal generation if you don't use them #net.inet6.ip6.accept_rtadv=0 #net.inet6.ip6.auto_linklocal=0 # Increases default TTL, sometimes useful # Default is 64 net.inet.ip.ttl=128 # Lessen max segment life to conserve resources # ACK waiting time in miliseconds # (default: 30000. RFC from 1979 recommends 120000) net.inet.tcp.msl=5000 # Max bumber of timewait sockets net.inet.tcp.maxtcptw=200000 # Don't use tw on local connections # As of 15 Apr 2009. Igor Sysoev says that nolocaltimewait has some buggy realization. # So disable it or now till get fixed #net.inet.tcp.nolocaltimewait=1 # FIN_WAIT_2 state fast recycle net.inet.tcp.fast_finwait2_recycle=1 # Time before tcp keepalive probe is sent # default is 2 hours (7200000) #net.inet.tcp.keepidle=60000 # Should be increased until net.inet.ip.intr_queue_drops is zero net.inet.ip.intr_queue_maxlen=4096 # Interrupt handling via multiple CPU, but with context switch. # You can play with it. Default is 1; #net.isr.direct=0 # This is for routers only #net.inet.ip.forwarding=1 #net.inet.ip.fastforwarding=1 # This speed ups dummynet when channel isn't saturated net.inet.ip.dummynet.io_fast=1 # Increase dummynet(4) hash #net.inet.ip.dummynet.hash_size=2048 #net.inet.ip.dummynet.max_chain_len # Should be increased when you have A LOT of files on server # (Increase until vfs.ufs.dirhash_mem becomes lower) vfs.ufs.dirhash_maxmem=67108864 # Note from commit http://svn.freebsd.org/base/head@211031 : # For systems with RAID volumes and/or virtualization envirnments, where # read performance is very important, increasing this sysctl tunable to 32 # or even more will demonstratively yield additional performance benefits. vfs.read_max=32 # Explicit Congestion Notification (see http://en.wikipedia.org/wiki/Explicit_Congestion_Notification) net.inet.tcp.ecn.enable=1 # Flowtable - flow caching mechanism # Useful for routers #net.inet.flowtable.enable=1 #net.inet.flowtable.nmbflows=65535 # Extreme polling tuning #kern.polling.burst_max=1000 #kern.polling.each_burst=1000 #kern.polling.reg_frac=100 #kern.polling.user_frac=1 #kern.polling.idle_poll=0 # IPFW dynamic rules and timeouts tuning # Increase dyn_buckets till net.inet.ip.fw.curr_dyn_buckets is lower net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_max=65536 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=2 net.inet.ip.fw.dyn_short_lifetime=10 # Make packets pass firewall only once when using dummynet # i.e. packets going thru pipe are passing out from firewall with accept #net.inet.ip.fw.one_pass=1 # shm_use_phys Wires all shared pages, making them unswappable # Use this to lessen Virtual Memory Manager's work when using Shared Mem. # Useful for databases #kern.ipc.shm_use_phys=1 # ZFS # Enable prefetch. Useful for sequential load type i.e fileserver. # FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 systems and # on any amd64 systems with less than 4GB of avaiable memory # For additional info check this nabble thread http://old.nabble.com/Samba-read-speed-performance-tuning-td27964534.html #vfs.zfs.prefetch_disable=0 # On highload servers you may notice following message in dmesg: # "Approaching the limit on PV entries, consider increasing either the # vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable" vm.pmap.shpgperproc=2048 loader.conf: # Accept filters for data, http and DNS requests # Useful when your software uses select() instead of kevent/kqueue or when you under DDoS # DNS accf available on 8.0+ accf_data_load="YES" accf_http_load="YES" accf_dns_load="YES" # Async IO system calls aio_load="YES" # Linux specific devices in /dev # As for 8.1 it only /dev/full #lindev_load="YES" # Adds NCQ support in FreeBSD # WARNING! all ad[0-9]+ devices will be renamed to ada[0-9]+ # 8.0+ only #ahci_load="YES" #siis_load="YES" # FreeBSD 8.2+ # New Congestion Control for FreeBSD # http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt # http://www.ietf.org/proceedings/78/slides/iccrg-5.pdf # Initial merge commit message http://www.mail-archive.com/[email protected]/msg31410.html #cc_chd_load="YES" # Increase kernel memory size to 3G. # # Use ONLY if you have KVA_PAGES in kernel configuration, and you have more than 3G RAM # Otherwise panic will happen on next reboot! # # It's required for high buffer sizes: kern.ipc.nmbjumbop, kern.ipc.nmbclusters, etc # Useful on highload stateful firewalls, proxies or ZFS fileservers # (FreeBSD 7.2+ amd64 users: Check that current value is lower!) #vm.kmem_size="3G" # If your server has lots of swap (>4Gb) you should increase following value # according to http://lists.freebsd.org/pipermail/freebsd-hackers/2009-October/029616.html # Otherwise you'll be getting errors # "kernel: swap zone exhausted, increase kern.maxswzone" # kern.maxswzone="256M" # Older versions of FreeBSD can't tune maxfiles on the fly #kern.maxfiles="200000" # Useful for databases # Sets maximum data size to 1G # (FreeBSD 7.2+ amd64 users: Check that current value is lower!) #kern.maxdsiz="1G" # Maximum buffer size(vfs.maxbufspace) # You can check current one via vfs.bufspace # Should be lowered/upped depending on server's load-type # Usually decreased to preserve kmem # (default is 10% of mem) #kern.maxbcache="512M" # Sendfile buffers # For i386 only #kern.ipc.nsfbufs=10240 # FreeBSD 9+ # HPET "legacy route" support. It should allow HPET to work per-CPU # See http://www.mail-archive.com/[email protected]/msg03603.html #hint.atrtc.0.clock=0 #hint.attimer.0.clock=0 #hint.hpet.0.legacy_route=1 # syncache Hash table tuning net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=512 net.inet.tcp.syncache.cachelimit=65536 # Increased hostcache # Later host cache can be viewed via net.inet.tcp.hostcache.list hidden sysctl # Very useful for it's RTT RTTVAR # Must be power of two net.inet.tcp.hostcache.hashsize=65536 # hashsize * bucketlimit (which is 30 by default) # It allocates 255Mb (1966080*136) of RAM net.inet.tcp.hostcache.cachelimit=1966080 # TCP control-block Hash table tuning net.inet.tcp.tcbhashsize=4096 # Disable ipfw deny all # Should be uncommented when there is a chance that # kernel and ipfw binary may be out-of sync on next reboot #net.inet.ip.fw.default_to_accept=1 # # SIFTR (Statistical Information For TCP Research) is a kernel module that # logs a range of statistics on active TCP connections to a log file. # See prerelease notes http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread/b4c18be6cdce76e4 # and man 4 sitfr #siftr_load="YES" # Enable superpages, for 7.2+ only # Also read http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030094.html vm.pmap.pg_ps_enabled=1 # Usefull if you are using Intel-Gigabit NIC #hw.em.rxd=4096 #hw.em.txd=4096 #hw.em.rx_process_limit="-1" # Also if you have ALOT interrupts on NIC - play with following parameters # NOTE: You should set them for every NIC #dev.em.0.rx_int_delay: 250 #dev.em.0.tx_int_delay: 250 #dev.em.0.rx_abs_int_delay: 250 #dev.em.0.tx_abs_int_delay: 250 # There is also multithreaded version of em/igb drivers can be found here: # http://people.yandex-team.ru/~wawa/ # # for additional em monitoring and statistics use # sysctl dev.em.0.stats=1 ; dmesg # sysctl dev.em.0.debug=1 ; dmesg # Also after r209242 (-CURRENT) there is a separate sysctl for each stat variable; # Same tunings for igb #hw.igb.rxd=4096 #hw.igb.txd=4096 #hw.igb.rx_process_limit=100 # Some useful netisr tunables. See sysctl net.isr #net.isr.maxthreads=4 #net.isr.defaultqlimit=4096 #net.isr.maxqlimit: 10240 # Bind netisr threads to CPUs #net.isr.bindthreads=1 # # FreeBSD 9.x+ # Increase interface send queue length # See commit message http://svn.freebsd.org/viewvc/base?view=revision&revision=207554 #net.link.ifqmaxlen=1024 # Nicer boot logo =) loader_logo="beastie" And finally here is KERNCONF: # Just some of them, see also # cat /sys/{i386,amd64,}/conf/NOTES # This one useful only on i386 #options KVA_PAGES=512 # You can play with HZ in environments with high interrupt rate (default is 1000) # 100 is for my notebook to prolong it's battery life #options HZ=100 # Polling is goot on network loads with high packet rates and low-end NICs # NB! Do not enable it if you want more than one netisr thread #options DEVICE_POLLING # Eliminate datacopy on socket read-write # To take advantage with zero copy sockets you should have an MTU >= 4k # This req. is only for receiving data. # Read more in man zero_copy_sockets # Also this epic thread on kernel trap: # http://kerneltrap.org/node/6506 # Here Linus says that "anybody that does it that way (FreeBSD) is totally incompetent" #options ZERO_COPY_SOCKETS # Support TCP sign. Used for IPSec options TCP_SIGNATURE # There was stackoverflow found in KAME IPSec stack: # See http://secunia.com/advisories/43995/ # For quick workaround you can use `ipfw add deny proto ipcomp` options IPSEC # This ones can be loaded as modules. They described in loader.conf section #options ACCEPT_FILTER_DATA #options ACCEPT_FILTER_HTTP # Adding ipfw, also can be loaded as modules options IPFIREWALL # On 8.1+ you can disable verbose to see blocked packets on ipfw0 interface. # Also there is no point in compiling verbose into the kernel, because # now there is net.inet.ip.fw.verbose tunable. #options IPFIREWALL_VERBOSE #options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_FORWARD # Adding kernel NAT options IPFIREWALL_NAT options LIBALIAS # Traffic shaping options DUMMYNET # Divert, i.e. for userspace NAT options IPDIVERT # This is for OpenBSD's pf firewall device pf device pflog # pf's QoS - ALTQ options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # Pretty console # Manual can be found here http://forums.freebsd.org/showthread.php?t=6134 #options VESA #options SC_PIXEL_MODE # Disable reboot on Ctrl Alt Del #options SC_DISABLE_REBOOT # Change normal|kernel messages color options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLACK) # More scroll space options SC_HISTORY_SIZE=8192 # Adding hardware crypto device device crypto device cryptodev # Useful network interfaces device vlan device tap #Virtual Ethernet driver device gre #IP over IP tunneling device if_bridge #Bridge interface device pfsync #synchronization interface for PF device carp #Common Address Redundancy Protocol device enc #IPsec interface device lagg #Link aggregation interface device stf #IPv4-IPv6 port # Also for my notebook, but may be used with Opteron device amdtemp # Same for Intel processors device coretemp # man 4 cpuctl device cpuctl # CPU control pseudo-device # Support for ECMP. More than one route for destination # Works even with default route so one can use it as LB for two ISP # For now code is unstable and panics (panic: rtfree 2) on route deletions. #options RADIX_MPATH # Multicast routing #options MROUTING #options PIM # Debug & DTrace options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic options KDTRACE_FRAME # amd64-only(?) options KDTRACE_HOOKS # all architectures - enable general DTrace hooks #options DDB #options DDB_CTF # all architectures - kernel ELF linker loads CTF data # Adaptive spining in lockmgr (8.x+) # See http://www.mail-archive.com/[email protected]/msg10782.html options ADAPTIVE_LOCKMGRS # UTF-8 in console (8.x+) #options TEKEN_UTF8 # FreeBSD 8.1+ # Deadlock resolver thread # For additional information see http://www.mail-archive.com/[email protected]/msg18124.html # (FYI: "resolution" is panic so use with caution) #options DEADLKRES # Increase maximum size of Raw I/O and sendfile(2) readahead #options MAXPHYS=(1024*1024) #options MAXBSIZE=(1024*1024) # For scheduler debug enable following option. # Debug will be available via `kern.sched.stats` sysctl # For more information see http://svnweb.freebsd.org/base/head/sys/conf/NOTES?view=markup #options SCHED_STATS If you are tuning network for maximum performance you may wish to play with ifconfig options like: # You can list all capabilities via `ifconfig -m` ifconfig [-]rxcsum [-]txcsum [-]tso [-]lro mtu In case you've enabled DDB in kernel config, you should edit your /etc/ddb.conf and add something like this to enable automatic reboot (and textdump as bonus): script kdb.enter.panic=textdump set; capture on; show pcpu; bt; ps; alltrace; capture off; call doadump; reset script kdb.enter.default=textdump set; capture on; bt; ps; capture off; call doadump; reset And do not forget to add ddb_enable="YES" to /etc/rc.conf Since FreeBSD 9 you can select to enable/disable flowcontrol on your NIC: # See http://en.wikipedia.org/wiki/Ethernet_flow_control and # http://www.mail-archive.com/[email protected]/msg07927.html for additional info ifconfig bge0 media auto mediaopt flowcontrol PS. Also most of FreeBSD's limits can be monitored by # vmstat -z and # limits PPS. variety of network counters can be monitored via # netstat -s In FreeBSD-9 netstat's -Q option appeared, try following command to display netisr stats # netstat -Q PPPS. also see # man 7 tuning PPPPS. I wanted to thank FreeBSD community, especially author of nginx - Igor Sysoev, nginx-ru@ and FreeBSD-performance@ mailing lists for providing useful information about FreeBSD tuning. FreeBSD WIP * Whats cooking for FreeBSD 7? * Whats cooking for FreeBSD 8? * Whats cooking for FreeBSD 9? So here is the question: What tunings are you using on yours FreeBSD servers? You can also post your /etc/sysctl.conf, /boot/loader.conf, kernel options, etc with description of its' meaning (do not copy-paste from sysctl -d). Don't forget to specify server type (web, smb, gateway, etc) Let's share experience!

  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

• SNAT through Racoon IPSec VPN

  - by Mite fine d'ailes

  I am trying to route traffic from a device (that I will call "target") connected to my Ubuntu box (that I will call "host") to servers at a remote office. The host uses a Racoon IPSec VPN, connected through a NIC called efix. This creates an aliased IF called efix:0 which has IP adress 192.168.190.132. It is able to reach the servers. The link between host and target is an Ethernet link, using IP adresses 10.0.0.1 on IF eusb for the host and 10.0.0.2 on IF eth0 for the target. I have setup the following routes and iptables entries: On target: 10.0.0.0 * 255.255.255.0 U 0 0 0 eth0 default 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 On host: echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to 192.168.190.132 iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT Using Wireshark to monitor an HTTP GET, I can see SYN packets from the target go all the way to the server, but the server's SYNACK packets stop at the host and are not forwarded to the target. Am I missing something here ? Isn't SNAT supposed to keep track of the connections ?

  Read the article

• How to determine which ports are open/closed on a FIREWALL?

  - by Rahl

  It seems no one has asked this question before (most regard host-based firewalls). Anyone familiar with port scanning tools (e.g. nmap) knows all about SYN scanning, FIN scanning, and the like to determine open ports on a host machine. Question is though, how do you determine the open ports on a firewall itself (disregard whether the host you're trying to connect to behind the firewall has those particular ports open or closed). This is assuming the firewall is blocking your IP connection. Example: We all communicate with serverfault.com through port 80 (web traffic). A scan on a host would reveal port 80 is open. If serverfault.com is behind a firewall and still allows this traffic through, then we can assume the firewall has port 80 open also. Now let's assume the firewall is blocking you (e.g. your IP address is under the deny list or is missing in the allowed list). You know port 80 has to be open (it works for appropriate IP addresses), but when you (the disallowed IP) attempt any scanning, all port scan attempts on the firewall drop the packet (including port 80, which we know to be open). So, how might we accomplish a direct firewall scan to reveal open/closed ports on the firewall itself, while still using the disallowed IP?

  Read the article

• tcp connect hangs on SYN_SENT if something listens, gets CONN_REFUSED if nothing listens

  - by Amos Shapira

  I'm hitting a very strange problem - when I try to connect to one of our servers the client hangs with SYN_SENT if something listens on the port (e.g. Apache on port 80, sshd on port 22 or SMTP on port 25) but if I try to connect to a port on which nothing listens then I immediately get a "CONNECTION refused" error. Connecting to other applications (e.g. rsyncd on some arbitrary port) succeeds. I ran tcpdump on the server and see that the SYN packets arrive to it but it only sends a response if nothing listens on that port. e.g.: on the server I run: # tcpdump -nn port 81 06:49:34.641080 IP 10.x.y.z.49829 server.81: S 3966400723:3966400723(0) win 12320 06:49:34.641118 IP server.81 x.y.z.49829: R 0:0(0) ack 3966400724 win 0 But if I listen on this port, e.g. with nc -4lvvv 81 & Then the output of tcpdump is: 06:44:31.063614 IP x.y.z.45954 server.81: S 3493682313:3493682313(0) win 12320 (and repeats until I stop it) The server is CentOS 5, the client is Ubuntu 11.04, the connection is done between two LAN's over per-user TCP OpenVPN. Connection to other servers on that network do not have a problem. Connecting from the other servers on the same network to that server works fine. Connections from other clients in our office over openvpn is also not a problem. What am I missing? Thanks.

  Read the article

• Some URLs fail to load on Windows web portal

  - by jpolache

  I’m working in a large data center and have been assigned to troubleshoot and issue with a windows (IIS) web server that acts as a portal for a customer of the data center. This portal server is on a DMZ at the local data center. I don’t have access to the portal desktop and am relying on an off-site administrator to work with me to do testing and report the condition of the portal. He tells me there are no software firewalls or other filtering configured. While most of the remote web pages work fine, several of the URSs the portal is suppose to serve up fail to load. I had wireshark installed on the portal system and had a capture taken of one of the failures. I used IE to access one of the remote web servers at issue. I could see the TCP SYN-ACK coming back from the remote server, but after several HTTP GETs fail to get a response the portal server sends a reset. The webmaster of the remote web server assures me that no sites are being blocked. I had a capture taken outside the local firewall, so there should be no issue there. Another tech set up a laptop and used the IP address of the portal (we took the portal off-line for the test). The laptop loads the URL as expected. I tried having Firefox loaded to make sure that the HTTP GET was not mal-formed. Same failure as with IE. So, it seems it is not the remote web server or the network, because there was no problem with the laptop. At this point, I’m not sure what other questions to ask or tests to do.

  Read the article

• Transparent proxying in MacOS X 10.6 Snow Leopard (and maybe FreeBSD)

  - by apenwarr

  I'm trying to create a transparent proxy on my MacOS machine in order to port the sshuttle ssh-based transproxy VPN from Linux. I think I almost have it working, but sadly, almost is not 100%. Short version is this. In one window, start something that listens on port 12300: $ while :; do nc -l 12300; done Now enable proxying: # sysctl -w net.inet.ip.forwarding=1 # sysctl -w net.inet.ip.fw.enable=1 # ipfw add 1000 fwd 127.0.0.1,12300 log tcp from any to any And now test it out: $ telnet localhost 9999 # any port number will do # this works; type stuff and you'll see it in the nc window $ telnet google.com 80 # any host/port will do # this *doesn't* work! After the latter experiment, I see lines like this in netstat: $ netstat -tn | grep ^tcp4 tcp4 0 0 66.249.91.104.80 192.168.1.130.61072 SYN_RCVD tcp4 0 0 192.168.1.130.61072 66.249.91.104.80 SYN_SENT The second socket belongs to my telnet program; the first is more suspicious. SYN_RCVD implies that my SYN packet was correctly captured by the firewall and taken in by the kernel, but apparently the SYNACK was never sent back to telnet, because it's still in SYN_SENT. On the other hand, if I kill the nc server, I get this: $ telnet google.com 80 Trying 66.249.81.104... telnet: connect to address 66.249.81.104: Connection refused telnet: Unable to connect to remote host ...which is as expected: my proxy server isn't running, so ipfw redirects my connection to port 12300, which has nobody listening on it, ie. connection refused. My uname says this: $ uname -a Darwin mean.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 Does anybody see any different results? (I'm especially interested in Snow Leopard vs Leopard results, as there seem to be some internet rumours that transproxy is broken in Snow Leopard version) Any advice for how to fix?

  Read the article

• File corrupted by some tools (probably virus or antivirus)- does the pattern indicate any known corruptions?

  - by StackTrace

  As part of our software we install postgres(windows). In one of the customer sites, a set of files got corrupted. All files were part of timezone information(postgres/share/timezone). They are some sort of binary files. After the corruption, they all starts with following pattern od -tac output $ od -tac GMT 0000000 can esc etx sub nak dle em | nl em so | o r l _ 030 033 003 032 025 020 031 | \n 031 016 | o r l _ 0000020 \ \ \ \ \ \ \ del 3 fs ] del del del del del \ \ \ \ \ \ \ 377 3 034 ] 377 377 377 377 377 0000040 > ack r v s ack p soh q h r s q w h q 276 206 362 366 363 206 360 201 361 350 362 363 361 367 350 361 0000060 t r ack h eot s } v h | etx p eot ack nul } 364 362 206 350 204 363 375 366 350 374 203 360 204 206 200 375 0000100 | q t s t 8 E E E E E E E E E E 374 361 364 363 364 270 305 305 305 305 305 305 305 305 305 305 0000120 E E E E E E E E E E E E E E E E 305 305 305 305 305 305 305 305 305 305 305 305 305 305 305 305 * 0000240 m ; z dc3 7 sub c can em a u 5 can d 2 B 355 ; z 023 267 232 343 230 031 a u 5 230 d 262 302 0000260 X nul y J o S - 9 ] stx soh L can 1 ! j 330 \0 y 312 o S 255 9 335 202 001 314 030 261 241 j 0000300 dle g o etb n ff em ] 9 F ' dc4 } , em $ 020 g 357 227 n \f 231 ] 271 F 247 024 375 254 231 244 0000320 Q si ff L bs 2 # stx i 5 r % | | c del Q 017 214 314 210 2 # 002 351 5 362 245 374 374 343 177 0000340 m C esc H em enq ~ X o V p / l dc3 N sp m C 033 H 031 205 376 X o 326 360 257 l 023 N 0000360 } ) enq ( syn ! 3 s $ E z dc3 A dc3 ff P

  Read the article

• Cisco ASA 8.2 ACL For NAT

  - by javano

  Sadly I have gone back in time to ASA 8.2(5)33 which I am not so familiar with. I have configured NAT between two interfaces but traffic isn't passing becasue I can't get the ACL to work; (The full config which isn't very big is here but to keep this post tidy I have just pasted the important parts below); interface Ethernet0/0 switchport access vlan 108 ! interface Ethernet0/6 switchport access vlan 104 ! interface Ethernet0/7 switchport access vlan 105 ! interface Vlan104 description BUILDING2 nameif BUILDING2 security-level 0 ip address 10.104.0.1 255.255.255.0 ! interface Vlan105 description BUILDING1 nameif BUILDING1 security-level 0 ip address 10.105.0.1 255.255.255.0 ! interface Vlan108 description Main LAN VLAN nameif lan security-level 0 ip address 172.22.0.215 255.255.255.0 ! object-group network obj_net_Remote_Hosts network-object host 111.111.111.3 network-object host 111.111.111.65 object-group network obj_host_pc1_eth1 network-object host 10.104.0.111 object-group network obj_host_pc2_eth1 network-object host 10.104.0.112 object-group network obj_host_pc3_eth1 network-object host 10.104.0.106 object-group network obj_host_pc4_eth1 network-object host 10.104.0.107 object-group network obj_net_PCs description IPs of PCs group-object obj_host_pc1_eth1 group-object obj_host_pc2_eth1 group-object obj_host_pc3_eth1 group-object obj_host_pc4_eth1 access-list acl_NAT_pc1_91 extended permit tcp host 10.104.0.111 host 111.111.111.3 eq 8101 access-list acl_Permit_PCs extended permit tcp object-group obj_net_PCs object-group obj_net_Remote_Hosts eq 8101 ! global (BUILDING1) 11 111.111.222.91 netmask 255.255.255.255 nat (BUILDING2) 11 access-list acl_NAT_pc1_91 access-group acl_Permit_PCs in interface BUILDING2 route BUILDING1 111.111.111.3 255.255.255.255 10.105.0.2 1 route BUILDING1 111.111.111.65 255.255.255.255 10.105.0.2 1 When I try and connect from PC1 to ip 111.111.111.3 I see the following error logged on the ASA console; %ASA-2-106001: Inbound TCP connection denied from 10.104.0.111/38495 to 111.111.111.3/8101 flags SYN on interface blades What the duce!

  Read the article

• Shorewall log question.

  - by Shikoru

  I have been getting various attempts to connect to ports on my shorewall firewall. The ports that I keep seeing connection attempts at are tcp 44444, tcp 44446, udp 55555 and every now and then some slight variation. I ran "netstat -a" and did not see anything listening on those ports. Is this something that I should be worried about or is it just some rouge computers out there? I have noticed alot of the ip addresses are from Spain and Mexico. May 25 18:39:35 Takkun kernel: [62516.626514] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:d0:b7:65:d4:13:34:ef:xx:xx:xx:81:08:00 SRC=200.124.9.113 DST=72.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=112 ID=51796 DF PROTO=TCP SPT=2071 DPT=44446 WINDOW=16384 RES=0x00 SYN URGP=0 May 25 18:39:52 Takkun kernel: [62535.433285] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:d0:b7:65:d4:13:34:ef:xx:xx:xx:81:08:00 SRC=72.50.95.174 DST=72.xxx.xxx.xxx LEN=90 TOS=0x00 PREC=0x00 TTL=105 ID=31130 PROTO=UDP SPT=59505 DPT=55555 LEN=70 May 25 18:40:05 Takkun kernel: [62548.963413] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:d0:b7:65:d4:13:34:ef:xx:xx:xx:81:08:00 SRC=77.12.37.1 DST=72.xxx.xxx.xxx LEN=90 TOS=0x00 PREC=0x00 TTL=108 ID=9585 PROTO=UDP SPT=20401 DPT=55555 LEN=70 That is the jist of what im seeing.

  Read the article

• Transparent proxying leaves sockets with SYN_RCVD in MacOS X 10.6 Snow Leopard (and maybe FreeBSD)

  - by apenwarr

  I'm trying to create a transparent proxy on my MacOS machine in order to port the sshuttle ssh-based transproxy VPN from Linux. I think I almost have it working, but sadly, almost is not 100%. Short version is this. In one window, start something that listens on port 12300: $ while :; do nc -l 12300; done Now enable proxying: # sysctl -w net.inet.ip.forwarding=1 # sysctl -w net.inet.ip.fw.enable=1 # ipfw add 1000 fwd 127.0.0.1,12300 log tcp from any to any And now test it out: $ telnet localhost 9999 # any port number will do # this works; type stuff and you'll see it in the nc window $ telnet google.com 80 # any host/port will do # this *doesn't* work! After the latter experiment, I see lines like this in netstat: $ netstat -tn | grep ^tcp4 tcp4 0 0 66.249.91.104.80 192.168.1.130.61072 SYN_RCVD tcp4 0 0 192.168.1.130.61072 66.249.91.104.80 SYN_SENT The second socket belongs to my telnet program; the first is more suspicious. SYN_RCVD implies that my SYN packet was correctly captured by the firewall and taken in by the kernel, but apparently the SYNACK was never sent back to telnet, because it's still in SYN_SENT. On the other hand, if I kill the nc server, I get this: $ telnet google.com 80 Trying 66.249.81.104... telnet: connect to address 66.249.81.104: Connection refused telnet: Unable to connect to remote host ...which is as expected: my proxy server isn't running, so ipfw redirects my connection to port 12300, which has nobody listening on it, ie. connection refused. My uname says this: $ uname -a Darwin mean.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 Does anybody see any different results? (I'm especially interested in Snow Leopard vs Leopard results, as there seem to be some internet rumours that transproxy is broken in Snow Leopard version) Any advice for how to fix?

  Read the article

• High load average due to high system cpu load (%sys)

  - by Nick

  We have server with high traffic website. Recently we moved from 2 x 4 core server (8 cores in /proc/cpuinfo), 32 GB RAM, running CentOS 5.x, to 2 x 4 core server (16 cores in /proc/cpuinfo), 32 GB RAM, running CentOS 6.3 Server running nginx as a proxy, mysql server and sphinx-search. Traffic is high, but mysql and sphinx-search databases are relatively small, and usually everything works blazing fast. Today server experienced load average of 100++. Looking at top and sar, we noticed that (%sys) is very high - 50 to 70%. Disk utilization was less 1%. We tried to reboot, but problem existed after the reboot. At any moment server had at least 3-4 GB free RAM. Only message shown by dmesg was "possible SYN flooding on port 80. Sending cookies.". Here is snippet of sar 11:00:01 CPU %user %nice %system %iowait %steal %idle 11:10:01 all 21.60 0.00 66.38 0.03 0.00 11.99 We know that this is traffic issue, but we do not know how to proceed future and where to check for solution. Is there a way we can find where exactly those "66.38%" are used. Any suggestions would be appreciated.

  Read the article

• Proxychains, Tortunnel, Privoxy: cannot connect() to port

  - by Benjamin

  Hi all, I'm trying to do an nmap scan through tor using tortunnel, privoxy and proxychains like explained in the following video: http://vimeo.com/6238958 I'm getting rather weird results. I can successfully perform any SYN scan on any port. However as soon as I try to do connect() scans, proxychains cannot connect itself to all ports. In other words, I can perform connect() scans to port 80: proxychains nmap -P0 -A -sV www.zzz.com -p80 but not port 21: proxychains nmap -P0 -A -sV www.zzz.net -p21 I get the following error: Starting Nmap 4.62 ( http://nmap.org ) at 2010-06-02 08:34 UTC ProxyChains-2.1 (http://proxychains.sf.net) random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 random chain (1):....127.0.0.1:5060....can't connect to..113.I2.1W1.YY:21 My only guess would be that the exit node I'm using does not allow connections to port 21. Would that be correct? How could I fix it? Thanks for your time.

  Read the article

• vim coloring for git

  - by kelloti

  I'm on Windows and my vim loads with a terrible colorscheme with vim. The message is blue on black (so I can't see what I'm typing). I need to change the colorscheme, but :colorscheme slate doesn't do anything. :version vim - vi improved 7.3 (2010 aug 15, compiled oct 27 2010 17:51:38) ms-windows 32-bit console version included patches: 1-46 compiled by bram@kibaale big version without gui. features included (+) or not (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +persistent_undo -postscript +printer -profile -python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save -xpm_w32 system vimrc file: "$vim\vimrc" user vimrc file: "$home\_vimrc" 2nd user vimrc file: "$vim\_vimrc" user exrc file: "$home\_exrc" 2nd user exrc file: "$vim\_exrc" compilation: cl -c /w3 /nologo -i. -iproto -dhave_pathdef -dwin32 -dfeat_cscope -dwinver=0x0400 -d_win32_winnt=0x0400 /fo.\objc/ /ox /gl -dndebug /zl /mt -ddynamic_iconv -ddynamic_gettext -dfeat_big /fd.\objc/ /zi linking: link /release /nologo /subsystem:console /ltcg:status oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib libcmt.lib user32.lib /pdb:vim.pdb -debug My $HOME\_vimrc looks like colorscheme slate syn on set shiftwidth=2 set tabstop=2 and my $VIM\vimrc is the stock vimrc that comes with the Windows Vim distribution. How do I change my console Vim colorscheme? Especially for Git commits.

  Read the article

• Port knocking via SSH tunnels

  - by j0ker

  I have a server running in my university's internal network. There is only one SSH daemon running which is secured by port knocking with knockd. Works fine if I try to connect from within the internal network. But since the server has no external IP, I have to tunnel into the internal network every time I want to access the server from outside. And since tunneling only works for a single port I cannot do the port knocking as easily as from an internal client. In fact, I don't get it to work at all. What I'm trying is opening tunnels for all the different ports that have to be knocked. Then I send TCP-SYN packets into the tunnels. But that doesn't work even for a single port. If I establish the tunnel on the first port in the knock sequence and send a packet through it, it doesn't reach the server. There is no entry in the log file of knockd, while there should be something like 123.45.67.89: openSSH: Stage 1 (as shown with internal knocks). So I guess, the problem doesn't exist within my knocking script but is a more general one. Are there any known problems with what I'm trying to do? Is it even possible or am I missing something? Thanks in advance!

  Read the article

• Apache suddenly very slow on http and faster on https

  - by hsnm

  Background: I have Apache 2 running on ubuntu. There is a low usage on it and mostly being accessed for a web service URL from mobile apps. It was working fine until I installed SSL certificates. I now have both http and https. When I access the server using https, I get a fairly quick response (but probably not as fast as before). When I use http, it's so slow. What I tried: From this post: I curl localhost from the host and it takes some time, meaning there is no routing issue. The server runs on Amazon EC2 instance and is managed by me only. Also: I see that Apache once running, creates the maximum number of processes it is allowed to, which was not the case before. I lowered the MaxClients to 20 and I think I'm getting faster responses but it still takes over a minute and I always have MaxClients Apache processes. dmesg returns many [ 1953.655703] TCP: Possible SYN flooding on port 80. Sending cookies. When I netstat I get many entries with SYN_RECV. Possibly a DDoS attack? From EC2's monitoring diagrams I see a pattern of high "Maximum Network In (Bytes)" since 2 days ago. By the way the server is still being tested, the actual traffic is very low and not consistent. I tried to go with this solution to limit incoming connections using iptables, still no luck, but I'm trying. Question: What could be the problem? Is this a DDoS attack?

  Read the article

• TCP dies on a Linux laptop

  - by Roman Cheplyaka

  Once in several days I have the following problem. My laptop (Debian GNU/Linux testing) suddenly becomes unable to work with TCP connections to the internet. The following things continue to work fine: UDP (DNS), ICMP (ping) — I get instant response TCP connections to other machines in the local network (e.g. I can ssh to a neighbour laptop) everything is ok for other machines in my LAN But when I try TCP connections from my laptop, they time out (no response to SYN packets). Here's a typical curl output: % curl -v google.com * About to connect() to google.com port 80 (#0) * Trying 173.194.39.105... * Connection timed out * Trying 173.194.39.110... * Connection timed out * Trying 173.194.39.97... * Connection timed out * Trying 173.194.39.102... * Timeout * Trying 173.194.39.98... * Timeout * Trying 173.194.39.96... * Timeout * Trying 173.194.39.103... * Timeout * Trying 173.194.39.99... * Timeout * Trying 173.194.39.101... * Timeout * Trying 173.194.39.104... * Timeout * Trying 173.194.39.100... * Timeout * Trying 2a00:1450:400d:803::1009... * Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable * Success * couldn't connect to host * Closing connection #0 curl: (7) Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable Restarting the connection and/or reloading the network card kernel module doesn't help. The only thing that helps is reboot. Clearly something is wrong with my system (everything else works fine), but I have no idea what exactly. I don't know how to reproduce this, but as I said, it happens every several days. My setup is a wireless router that is connected to the ISP via PPPoE. Any advice?

  Read the article

• OpenSSL force client to use specific protocol

  - by Ex Umbris

  When subversion attempts to connect to an https URL, the underlying protocol library (openssl) attempts to start the secure protocol negotiation at the most basic level, plain SSL. Unfortunately, I have to connect to a server that requires SSL3 or TLS1, and refuses to respond to SSL or SSL2. I’ve done some troubleshooting using s_client and confirmed that if I let s_client start with the default protocol the server never responds to the CLIENT HELLO: $ openssl s_client -connect server.domain.com:443 CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 320 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Watching this in Wireshark I see: Client Server -------syn----------> <------ack----------- ---CLIENT HELLO-----> <------ack----------- [60 second pause] <------rst----------- If I tell s_client to use ssl2 the server immediately closes the connection. Only ssl3 and tls1 work. Is there any way to configure openssl to skip SSL and SSL2, and start the negotiation with TLS or SSL3? I've found the OpenSSL config file, but that seems to control only certificate generation.

  Read the article

• Windows Server 2008 IIS Random disconnect

  - by d123

  I am having a bit of a quirk with my IIS server. I'm running my IIS with 2 sets of IPs configured, one in the 192 range and the other in 172 range. I then have multiple apps which will talk to this server for information. Server has no AV or firewalls configured. I noticed that my apps when talking to the server on the 172 range, at random intervals, the server would just not respond. My apps would then disconnect and just try again, and every thing would be fine. This doesn't happen on the 192 range. So what I did is on a Linux box I did a watch command and to wget a file every half second on the 172 and 192 IPs. I noticed the same issue, every once in awhile wget on the 172 range would not get through, but there is no issues at all on 192. Thus I went around to Wireshark and did a dump. This is the last 3 packets, no other packets were received. 7010 100.871877 200.100.30.7 172.0.0.1 TCP 59619 http [ACK] Seq=140 Ack=85242 Win=64128 Len=0 TSV=1072818795 TSER=1660246133 7011 100.872238 200.100.30.7 172.0.0.1 TCP 59619 http [FIN, ACK] Seq=140 Ack=85242 Win=64128 Len=0 TSV=1072818796 TSER=1660246133 7013 100.873081 200.100.30.7 172.0.0.1 TCP 59619 http [ACK] Seq=141 Ack=85243 Win=64128 Len=0 TSV=1072818796 TSER=1660246133 So this is my issue, there is a random disconnect every once in awhile. The server doesn't receive the next SYN packet. HELP?

  Read the article

< Previous Page | 37 38 39 40 41 42 43 44 45 46 47 48  | Next Page >