Search Results

Search found 20693 results on 828 pages for '24 hours of pass'.

Page 110/828 | < Previous Page | 106 107 108 109 110 111 112 113 114 115 116 117  | Next Page >

• Comparing date range quarters sql server

  - by CR41G14

  I have a policies in a system PolRef Start End POL123 22/11/2012 23/12/2014 POL212 24/09/2012 23/10/2012 POL214 23/08/2012 29/09/2012 I am asking a user for a reporting date, the user enters 24/10/2012 this becomes @StartDate From this I derive what the quarter is by the month: set @currentMonth = Month(@StartDate) if @currentMonth = 1 or @currentMonth = 2 or @currentMonth = 3 begin set @startmonth = 1 set @endmonth = 3 end if @currentMonth = 4 or @currentMonth = 5 or @currentMonth = 6 begin set @startmonth = 4 set @endmonth = 6 end if @currentMonth = 7 or @currentMonth = 8 or @currentMonth = 9 begin set @startmonth = 7 set @endmonth = 9 end if @currentMonth = 10 or @currentMonth = 11 or @currentMonth = 12 begin set @startmonth = 10 set @endmonth = 12 end I then get a date range: @quarterStartDate = CAST(CAST(YEAR(@StartDate) AS varchar) + '-' + CAST(@startMonth AS varchar) + '-' + '01') AS Date) @quarterEndDate = CAST(CAST(YEAR(@EcdDate) AS varchar) + '-' + CAST(@endMonth AS varchar) + '-' + '31') AS Date) This will give me 01-10-2012 and 31-12-2012. Basically I need a script to only bring back the policies that are in this quarter. The policy doesn't have to span the entire quarter date range, just exist in the quarter date range. The results expected would be PolRef Start End POL123 22/11/2012 23/12/2014 POL212 24/09/2012 23/10/2012 Pol123 appears because it spans over the quarterly date range. Pol212 is there because it expires in that quarter date range. Pol214 does not appear because it neither spans, expires or starts in this quarter. Any help would be greatly appreciated

  Read the article

• PHP date/time help/

  - by NOW

  I keep getting a value of 0 for $years and $months when there should be a value other then 0 can someone tell me what I'm doing wrong with my code? And what I need to fix? I'm trying to subtract two dates. Here is my PHP code. $delete_date = "2000-01-12 08:02:39"; $current_date = date('Y-m-d H:i:s'); //current date $diff = abs(strtotime($current_date) - strtotime($delete_date)); $years = floor($diff / (365*60*60*24)); $months = floor(($diff - $years * 365*60*60*24) / (30*60*60*24)); echo $current_date . '<br />'; echo $delete_date. '<br />'; echo $diff. '<br />'; echo $years. '<br />'; echo $months. '<br />';

  Read the article

• The SVG text node disappear after change its text content

  - by sureone

  svg: <text xml:space="preserve" y="228" x="349.98" text-anchor="middle" stroke-width="0" stroke-linejoin="null" stroke-linecap="null" stroke-dasharray="null" stroke="#000000" fill="#000000" style="cursor: move; pointer-events: inherit;" font-size="24" font-family="serif" id="cur_b">cur_b</text> <text xml:space="preserve" y="222" x="103.98" text-anchor="middle" stroke-width="0" stroke-linejoin="null" stroke-linecap="null" stroke-dasharray="null" stroke="#000000" fill="#000000" style="cursor: move; pointer-events: inherit;" font-size="24" font-family="serif" id="cur_a">cur_a</text> <text xml:space="preserve" y="229" x="590.0211" text-anchor="middle" stroke-width="0" stroke-linejoin="null" stroke-linecap="null" stroke-dasharray="null" stroke="#000000" fill="#000000" style="cursor: move; pointer-events: inherit;" font-size="24" font-family="serif" id="cur_c">cur_c</text> NSString* theJS = @ "var theNode0 = document.getElementById('cur_a'); theNode0.textContent='200A'; theNode0.setAttribute('fill','#FF0000'); var theNode1 = document.getElementById('cur_c'); theNode1.textContent='200A'; theNode1.setAttribute('fill','#00FF00');" [self.webView stringByEvaluatingJavaScriptFromString:theJS]; The SVG text node value is changed but disappeared after about one second.

  Read the article

• ZTE USB Modem AC2736, connection not possible in Ubuntu 12.04.1 LTS

  - by Fredo

  It's a long post but nearly covers all my experiments and changes I did to my NM. Hope the information is complete and if there are still question, more information can be provided. I've a ZTE AC2736 USB Modem (CDMA modem) which worked fine in Ubuntu 10.04 /11.10. I recently switched to 12.04.1 (precise pangolin). after the switch the first issue I faced was to connect to internet using my USB modem (ISP: Reliance Brand: Netconnect). Tried to run the drivers provided by Reliance but they are old and won't support Kernel 2.6.30 above. since the code was not downloaded with ISO image (of 12.04) i couldn't compile the files provided in such driver. lsusb does detect it as Modem with output similar to 19d2:fff1 ZTE CDMA technologies inc. (or similar as i didn't note it down) If it is detected as USB storage it shows 19d2:fff5 (as per few online forums, i may be wrong here). I used the network Manager and configured the modem to dial #777 (default) and the ISP provided username:password combination. It tries to connect to internet (3-4 times automatically)but fails to get online. once I was able to connect in the monring hours and the message was flashed 'registered on CDMA home network'. I was able to run an update. the kernel was updated with 3.0.2 -pae OR something similar (can find out if required). I surfed the net for about 2 hours later before restarting. After the restart, again the Modem was not able to get me online. I kept trying for many times. I tried changing the setting in NM. One evening after dark I was able to connect to network with same message flash 'registered on CDMA home network' (the message was similar, i'm not precise here,sorry). I was able to surf the net for nearly 3 hours before I switched off my Laptop. I'm not able to get online after that day, It's been 3 days now. I'll try the observered theory of late/early hours sometime soon as mentioned below. Laptop configuration : Make: Lenovo Model: B480 Processor: Intel B950 RAM: 4G DDR3 HDD: 500 G Broadcom Wireless/Bluetooth/Ethernet LAN OS: FreeDOS / Ubuntu 12.04 LTS (dualboot) Kernel 3.0.2-pae Obeservation : I'm able to connect to internet in those hours when generally the speed is high (low usage by other network (wireless) users). like in early mornings or late nights. This is strange as connection should not be dependent on bandwidth usage. Any help would be appraciated to fix this issue. before I decide to cahnge the OS or ISP.

  Read the article

• How do I set up nvidia graphics adapter to put out 1080p, it seems to be using interlace mode>

  - by keepitsimpleengineer

  After upgrading to 12.04, my mythbuntu client/server seems to be running in 1080i, the clue comes from: [ 1176.117] (II) NVIDIA(0): Setting mode "1920x1080_60i" [ 1231.340] (II) NVIDIA(0): Setting mode "DFP-1:1920x1080_60@1920x1080+0+0" This is from Xorg.0.log. This whole thing started from video tearing when watching Mythtv recordings. It didn't happen in 10.10. Should I use "TVStandard" "HD1080p" in the screen section since this is a dedicated HTPC? It only connects to an HDTV (1080p) via hdmi. Here is the current xorg.conf file: # nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 270.29 (buildd@allspice) Fri Feb 25 14:42:07 UTC 2011 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 # commented out by update-manager, HAL is now used and auto-detects devices # Keyboard settings are now read from /etc/default/console-setup # InputDevice "Keyboard0" "CoreKeyboard" # commented out by update-manager, HAL is now used and auto-detects devices # Keyboard settings are now read from /etc/default/console-setup # InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" FontPath "unix/:7100" EndSection # commented out by update-manager, HAL is now used and auto-detects devices # Keyboard settings are now read from /etc/default/console-setup #Section "InputDevice" # # generated from default # Identifier "Mouse0" # Driver "mouse" # Option "Protocol" "auto" # Option "Device" "/dev/psaux" # Option "Emulate3Buttons" "no" # Option "ZAxisMapping" "4 5" #EndSection # commented out by update-manager, HAL is now used and auto-detects devices # Keyboard settings are now read from /etc/default/console-setup #Section "InputDevice" # # generated from default # Identifier "Keyboard0" # Driver "kbd" #EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "Unknown" ModelName "SAMSUNG" HorizSync 26.0 - 81.0 VertRefresh 24.0 - 75.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce GT 240" Option "TripleBuffer" "1" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "TwinView" "0" Option "metamodes" "DFP: nvidia-auto-select +0+0" SubSection "Display" Depth 24 EndSubSection EndSection After a little digging, the question changes slightly, to wit... Per Chapter 19 of nvidia README... "If the EDID for the display device reported a preferred mode timing, and that mode timing is considered a valid mode, then that mode is used as the "nvidia-auto-select" mode." The EDID for my HDMI connected LCD monitor says use first device as preferred. Prefer first detailed timing : Yes Also: (--) NVIDIA(0): EDID maximum pixel clock : 230.0 MHz The list: (from startx -- -verbose 6 ) (--) NVIDIA(0): Detailed Timings: (--) NVIDIA(0): 1920 x 1080 @ 60 Hz (--) NVIDIA(0): Pixel Clock : 148.50 MHz (--) NVIDIA(0): HRes, HSyncStart : 1920, 2008 (--) NVIDIA(0): HSyncEnd, HTotal : 2052, 2200 (--) NVIDIA(0): VRes, VSyncStart : 1080, 1084 (--) NVIDIA(0): VSyncEnd, VTotal : 1089, 1125 (--) NVIDIA(0): H/V Polarity : +/+ This is the actual mode selected: (from xorg.0.log) (--) NVIDIA(0): 1920 x 1080 @ 60 Hz (--) NVIDIA(0): Pixel Clock : 74.18 MHz (--) NVIDIA(0): HRes, HSyncStart : 1920, 2008 (--) NVIDIA(0): HSyncEnd, HTotal : 2052, 2200 (--) NVIDIA(0): VRes, VSyncStart : 1080, 1084 (--) NVIDIA(0): VSyncEnd, VTotal : 1094, 1124 (--) NVIDIA(0): H/V Polarity : +/+ (--) NVIDIA(0): Extra : Interlaced (--) NVIDIA(0): CEA Format : 5 So my HTPC is down-converting to 1080i and then the Monitor is up-converting to 1080p How can I fix this, please?

  Read the article

• Games at Work Part 1: Introduction to Gamification and Applications

  - by ultan o'broin

  Games Are Everywhere How many of you (will admit to) remember playing Pong? OK then, do you play Angry Birds on your phone during work hours? Thought about why we keep playing online, video, and mobile games and what this "gamification" business we're hearing about means for the enterprise applications user experience? In Reality Is Broken: Why Games Make Us Better and How They Can Change the World, Jane McGonigal says that playing computer and online games now provides more rewards for people than their real lives do. Games offer intrinsic rewards and happiness to the players as they pursue more satisfying work and the success, social connection, and meaning that goes with it. Yep, Gran Turismo, Dungeons & Dragons, Guitar Hero, Mario Kart, Wii Boxing, and the rest are all forms of work it seems. Games are, in fact, work taken so seriously that governments now move to limit the impact of virtual gaming currencies on the real financial system. Anyone who spends hours harvesting crops on FarmVille realizes it’s hard work too. Yet games evoke a positive emotion in players who voluntarily stay engaged with games for hours, day after day. Some 183 million active gamers in the United States play on average 13 hours per week. Weekly, 5 million of those gamers play for longer than a working week (45 hours). So why not harness the work put into games to solve real-world problems? Or, in the case of our applications users, real-world work problems? What’s a Game? Jane explains that all games have four defining traits: a goal, rules, a feedback system, and voluntary participation. We need to look at what motivational ideas behind the dynamics of the game—what we call gamification—are appropriate for our users. Typically, these motivators are achievement, altruism, competition, reward, self-expression, and status). Common game techniques for leveraging these motivations include: Badging and avatars Points and awards Leader boards Progress charts Virtual currencies or goods Gifting and giving Challenges and quests Some technology commentators argue for a game layer on top of everything, but this layer is already part of our daily lives in many instances. We see gamification working around us already: the badging and kudos offered on My Oracle Support or other Oracle community forums, becoming a Dragon Slayer implementor of Atlassian applications, being made duke of your favorite coffee shop on Yelp, sharing your workout details with Nike+, or donating to Japanese earthquake relief through FarmVille, for example. And what does all this mean for the applications that you use in your work? Read on in part two...

  Read the article

• What's a reliable and practical way to protect software with a user license ?

  - by Frank

  I know software companies use licenses to protect their softwares, but I also know there are keygen programs to bypass them. I'm a Java developer, if I put my program online for sale, what's a reliable and practical way to protect it ? How about something like this, would it work ? <1> I use ProGuard to protect the source code. <2> Sign the executable Jar file. <3> Since my Java program only need to work on PC [I need to use JDIC in it], I wrap the final executable Jar into an .exe file which makes it harder to decompile. <4> When a user first downloads and runs my app, it checks for a Pass file on his PC. <5> If the Pass file doesn't exist, run the app in demo mode, exits in 5 minutes. <6> When demo exits a panel opens with a "Buy Now" button. This demo mode repeats forever unless step <7> happens. <7> If user clicks the "Buy Now" button, he fills out a detailed form [name, phone, email ...], presses a "Verify Info" button to save the form to a Pass file, leaving license Key # field empty in this newly generated Pass file. <8> Pressing "Verify Info" button will take him to a html form pre-filled with his info to verify what he is buying, also hidden in the form's input filed is a license Key number. He can now press a "Pay Now" button to goto Paypal to finish the process. <9> The hidden license Key # will be passed to Paypal as product Id info and emailed to me. <10> After I got the payment and Paypal email, I'll add the license Key # to a valid license Key list, and put it on my site, only I know the url. The list is updated hourly. <11> Few hours later when the user runs the app again, it can find the Pass file on his PC, but the license Key # value is empty, so it goes to the valid list url to see if its license Key # is on the list, if so, write the license Key # into the Pass file, and the next time it starts again, it will find the valid license Key # and start in purchased mode without exiting in 5 minutes. <12> If it can't find its license Key # on the list from my url, run in demo mode. <13> In order to prevent a user from copying and using another paid user's valid Pass file, the license Key # is unique to each PC [I'm trying to find how], so a valid Pass file only works on one PC. Only after a user has paid will Paypal email me the valid license Key # with his payment. <14> The Id checking goes like this : Use the CPU ID : "CPU_01-02-ABC" for example, encrypt it to the result ID : "XeR5TY67rgf", and compare it to the list on my url, if "XeR5TY67rgf" is not on my valid user list, run in demo mode. If it exists write "XeR5TY67rgf" into the Pass File license field. In order to get a unique license Key, can I use his PC's CPU Id ? Or something unique and useful [ relatively less likely to change ]. If so let's say this CPU ID is "CPU_01-02-ABC", I can encrypt it to something like "XeR5TY67rgf", and pass it to Paypal as product Id in the hidden html form field, then I'll get it from Paypal's email notification, and add it to the valid license Key # list on the url. So, even if a hacker knows it uses CPU Id, he can't write it into the Pass file field, because only encrypted Ids are valid Ids. And only my program knows how to generate the encrypted Ids. And even if another hacker knows the encrypted Id is hidden in the html form input field, as long as it's not on my url list, it's still invalid. Can anyone find any flaw in the above system ? Is it practical ? And most importantly how do I get hold of this unique ID that can represent a user's PC ? Frank

  Read the article

• pfsense 2.0.1 Firewall SMB Share not showing up under network

  - by atrueresistance

  I have a freenas NAS with a SMB share running at 192.168.2.2 of a 192.168.2.0/28 network. Gateway is 192.168.2.1. Originally this was running on a switch with my LAN, but now having upgraded to new hardware the Freenas has it's own port on the firewall. Before the switch the freenas would show up under Network on a windows 7 box and an OSX Lion box as freenas{wins} or CIFS shares on freenas{osx} so I know it doesn't have anything do to with the freenas. Here are my pfsense rules. ID Proto Source Port Destination Port Gateway Queue Schedule Description PASS TCP FREENAS net * LAN net 139 (NetBIOS-SSN) * none cifs lan passthrough PASS TCP FREENAS net * LAN net 389 (LDAP) * none cifs lan passthrough PASS TCP FREENAS net * LAN net 445 (MS DS) * none cifs lan passthrough PASS UDP FREENAS net * LAN net 137 (NetBIOS-NS) * none cifs lan passthrough PASS UDP FREENAS net * LAN net 138 (NetBIOS-DGM) * none cifs lan passthrough BLOCK * FREENAS net * LAN net * * none BLOCK * FREENAS net * OPTZONE net * * none BLOCK * FREENAS net * 192.168.2.1 * * none PASS * FREENAS net * * * * none BLOCK * * * * * * none I can connect if I use \\192.168.2.2 and enter the correct login details. I would just like this to show up on the network. Nothing in the log seems to be blocked when I filter by 192.168.2.2. What port am I missing for SMB to show up under the network and not have to connect by IP? ps. Do I really need the LDAP rule?

  Read the article

• using pf for packet filtering and ipfw's dummynet for bandwidth limiting at the same time

  - by krdx

  I would like to ask if it's fine to use pf for all packet filtering (including using altq for traffic shaping) and ipfw's dummynet for bandwidth limiting certain IPs or subnets at the same time. I am using FreeBSD 10 and I couldn't find a definitive answer to this. Googling returns such results as: It works It doesn't work Might work but it's not stable and not recommended It can work as long as you load the kernel modules in the right order It used to work but with recent FreeBSD versions it doesn't You can make it work provided you use a patch from pfsense Then there's a mention that this patch might had been merged back to FreeBSD, but I can't find it. One certain thing is that pfsense uses both firewalls simultaneously so the question is, is it possible with stock FreeBSD 10 (and where to obtain the patch if it's still necessary). For reference here's a sample of what I have for now and how I load things /etc/rc.conf ifconfig_vtnet0="inet 80.224.45.100 netmask 255.255.255.0 -rxcsum -txcsum" ifconfig_vtnet1="inet 10.20.20.1 netmask 255.255.255.0 -rxcsum -txcsum" defaultrouter="80.224.45.1" gateway_enable="YES" firewall_enable="YES" firewall_script="/etc/ipfw.rules" pf_enable="YES" pf_rules="/etc/pf.conf" /etc/pf.conf WAN1="vtnet0" LAN1="vtnet1" set skip on lo0 set block-policy return scrub on $WAN1 all fragment reassemble scrub on $LAN1 all fragment reassemble altq on $WAN1 hfsc bandwidth 30Mb queue { q_ssh, q_default } queue q_ssh bandwidth 10% priority 2 hfsc (upperlimit 99%) queue q_default bandwidth 90% priority 1 hfsc (default upperlimit 99%) nat on $WAN1 from $LAN1:network to any -> ($WAN1) block in all block out all antispoof quick for $WAN1 antispoof quick for $LAN1 pass in on $WAN1 inet proto icmp from any to $WAN1 keep state pass in on $WAN1 proto tcp from any to $WAN1 port www pass in on $WAN1 proto tcp from any to $WAN1 port ssh pass out quick on $WAN1 proto tcp from $WAN1 to any port ssh queue q_ssh keep state pass out on $WAN1 keep state pass in on $LAN1 from $LAN1:network to any keep state /etc/ipfw.rules ipfw -q -f flush ipfw -q add 65534 allow all from any to any ipfw -q pipe 1 config bw 2048KBit/s ipfw -q pipe 2 config bw 2048KBit/s ipfw -q add pipe 1 ip from any to 10.20.20.4 via vtnet1 out ipfw -q add pipe 2 ip from 10.20.20.4 to any via vtnet1 in

  Read the article

• HAProxy: Display a "BADREQ" | BADREQ's by the thousands

  - by GruffTech

  My HAProxy Configuration. #HA-Proxy version 1.3.22 2009/10/14 Copyright 2000-2009 Willy Tarreau <[email protected]> global maxconn 10000 spread-checks 50 user haproxy group haproxy daemon stats socket /tmp/haproxy log localhost local0 log localhost local1 notice defaults mode http maxconn 50000 timeout client 10000 option forwardfor except 127.0.0.1 option httpclose option httplog listen dcaustin 0.0.0.0:80 mode http timeout connect 12000 timeout server 60000 timeout queue 120000 balance roundrobin option httpchk GET /index.html log global option httplog option dontlog-normal server web1 10.10.10.101:80 maxconn 300 check fall 1 server web2 10.10.10.102:80 maxconn 300 check fall 1 server web3 10.10.10.103:80 maxconn 300 check fall 1 server web4 10.10.10.104:80 maxconn 300 check fall 1 listen stats 0.0.0.0:9000 mode http balance log global timeout client 5000 timeout connect 4000 timeout server 30000 stats uri /haproxy HAProxy is running, and the socket is working... adam@dcaustin:/etc/haproxy# echo "show info" | socat stdio /tmp/haproxy Name: HAProxy Version: 1.3.22 Release_date: 2009/10/14 Nbproc: 1 Process_num: 1 Pid: 6320 Uptime: 0d 0h14m58s Uptime_sec: 898 Memmax_MB: 0 Ulimit-n: 20017 Maxsock: 20017 Maxconn: 10000 Maxpipes: 0 CurrConns: 47 PipesUsed: 0 PipesFree: 0 Tasks: 51 Run_queue: 1 node: dcaustin desiption: Errors show nothing from socket... adam@dcaustin:/etc/haproxy# echo "show errors" | socat stdio /tmp/haproxy adam@dcaustin:/etc/haproxy# However... My Error log is exploding with "badrequests" with the Error code cR. cR (according to 1.3 documentation) is The "timeout http-request" stroke before the client sent a full HTTP request. This is sometimes caused by too large TCP MSS values on the client side for PPPoE networks which cannot transport full-sized packets, or by clients sending requests by hand and not typing fast enough, or forgetting to enter the empty line at the end of the request. The HTTP status code is likely a 408 here. Correct on the 408, but we're getting literally thousands of these requests every hour. (This log snippet is an clip for about 10 seconds of time...) Jun 30 11:08:52 localhost haproxy[6320]: 92.22.213.32:26448 [30/Jun/2011:11:08:42.384] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10002 408 212 - - cR-- 35/35/18/0/0 0/0 "<BADREQ>" Jun 30 11:08:54 localhost haproxy[6320]: 71.62.130.24:62818 [30/Jun/2011:11:08:44.457] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 39/39/16/0/0 0/0 "<BADREQ>" Jun 30 11:08:55 localhost haproxy[6320]: 84.73.75.236:3589 [30/Jun/2011:11:08:45.021] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10008 408 212 - - cR-- 35/35/15/0/0 0/0 "<BADREQ>" Jun 30 11:08:55 localhost haproxy[6320]: 69.39.20.190:49969 [30/Jun/2011:11:08:45.709] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 37/37/16/0/0 0/0 "<BADREQ>" Jun 30 11:08:56 localhost haproxy[6320]: 2.29.0.9:58772 [30/Jun/2011:11:08:46.846] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 43/43/22/0/0 0/0 "<BADREQ>" Jun 30 11:08:57 localhost haproxy[6320]: 212.139.250.242:57537 [30/Jun/2011:11:08:47.568] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 42/42/21/0/0 0/0 "<BADREQ>" Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55046 [30/Jun/2011:11:08:48.559] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 46/46/24/0/0 0/0 "<BADREQ>" Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55044 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10004 408 212 - - cR-- 45/45/24/0/0 0/0 "<BADREQ>" Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55045 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10005 408 212 - - cR-- 44/44/24/0/0 0/0 "<BADREQ>" Jun 30 11:09:00 localhost haproxy[6320]: 68.197.56.2:52781 [30/Jun/2011:11:08:50.975] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 49/49/28/0/0 0/0 "<BADREQ>" From what I read on google, if i wanted to see what the bad requests are, I can show errors to the socket and it will spit them out. We do run a pretty heavily trafficed website and the percentage of "BADREQS" to normal requests is quite low, but I'd like to be able to get ahold of what that request WAS so I can debug it. stats # pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max, dcaustin,FRONTEND,,,64,120,50000,88433,105889100,2553809875,0,0,4641,,,,,OPEN,,,,,,,,,1,1,0,,,,0,45,0,128, dcaustin,web1,0,0,10,28,300,20941,25402112,633143416,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,1,,20941,,2,11,,30, dcaustin,web2,0,0,9,30,300,20941,25026691,641475169,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,2,,20941,,2,11,,30, dcaustin,web3,0,0,10,27,300,20940,30116527,635015040,,0,,0,9,0,0,UP,1,1,0,0,0,2208,0,,1,1,3,,20940,,2,10,,31, dcaustin,web4,0,0,5,28,300,20940,25343770,643209546,,0,,0,8,0,0,UP,1,1,0,0,0,2208,0,,1,1,4,,20940,,2,11,,31, dcaustin,BACKEND,0,0,34,95,50000,83762,105889100,2553809875,0,0,,0,34,0,0,UP,4,4,0,,0,2208,0,,1,1,0,,83762,,1,43,,122, 88500 "Sessions" and 4500 errors. in the last 20 minutes.

  Read the article

• Fedora 12 Wireless problems (Intel Wireless 4965AGN Card)

  - by Ninefingers

  Hi All, I'm having an interesting experience with my wireless card at the moment. Basically, it does like this: I connect to the local wireless network (netgear router) It works, briefly, allowing me to browse a webpage or maybe two, if I'm lucky. It then stops working / sending any packets, whilst reported still connected. Now, me being me I've had a look to see what I can find. wpa_supplicant.log looks like this: Trying to associate with valid_mac:a2:30 (SSID='vennardwireless' freq=2462 MHz) Associated with valid_mac:a2:30 WPA: Key negotiation completed with valid_mac:a2:30 [PTK=CCMP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to valid_mac:a2:30 completed (reauth) [id=0 id_str=] CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys So that's working fine. dmesg | grep "*iwl*" spits out this: iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kds iwlagn: Copyright(c) 2003-2009 Intel Corporation iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 iwlagn 0000:03:00.0: setting latency timer to 64 iwlagn 0000:03:00.0: Detected Intel Wireless WiFi Link 4965AGN REV=0x4 iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels iwlagn 0000:03:00.0: irq 32 for MSI/MSI-X phy0: Selected rate control algorithm 'iwl-agn-rs' iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode iwlagn 0000:03:00.0: loaded firmware version 228.61.2.24 Registered led device: iwl-phy0::radio Registered led device: iwl-phy0::assoc Registered led device: iwl-phy0::RX Registered led device: iwl-phy0::TX iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:24:b2:32:a3:30 tid = 0 iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:24:b2:32:a3:30 tid = 0 So that's working too. I can also ping 192.168.0.1 -I wlan0 and arping 192.168.0.1 -I wlan0 the router until the network falls over. uname -r:2.6.32.10-90.fc12.x86_64. Laptop is a Core2 Duo (2Ghz) with 3GB RAM. Other symptoms I've noticed are that wireshark freezes when I capture on the "broken" interface until I disconnect. Am using networkmanager as per normal. Stupidly, I can connect to the same router via eth0/a cat6 cable just fine. Everyone else can connect to the AP fine (from Windows). Yes, I'm sat right next to it and not trying to access a hotspot the other side of the world. Any ideas? Is this a broken update? (I intend to reboot and test an older kernel later)? Anyone else come across this? Edit: iwconfig wlan0 rate auto is the settings I'm using for rates. Also, according to networkmanager the network is still connected. Thanks for any pointers / advice.

  Read the article

• Httpd problem, suspect an attack but not sure

  - by Bob

  On one of my servers when I type netstat -n I get a huge output, something like 400 entries for httpd. The bandwidth on the server isn't high, so I'm confused as to what's causing it. I'm suspecting an attack, but not sure. Intermittently, the web server will stop responding. When this happens all other services such as ping, ftp, work just normally. System load is also normal. The only thing that isn't normal I think is the "netstat -n" output. Can you guys take a look and see if there's something I can do? I have APF installed, but not sure what rules I should put into place to mitigate the problem. Btw, I'm running CentOS 5 Linux with Apache 2. root@linux [/backup/stuff/apf-9.7-1]# netstat -n|grep :80 tcp 0 0 120.136.23.56:80 220.181.94.220:48397 TIME_WAIT tcp 0 0 120.136.23.56:80 218.86.49.153:1734 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48316 TIME_WAIT tcp 0 0 120.136.23.56:80 208.80.193.33:54407 TIME_WAIT tcp 0 0 120.136.23.56:80 65.49.2.180:46768 TIME_WAIT tcp 0 0 120.136.23.56:80 120.0.70.180:9414 FIN_WAIT2 tcp 0 0 120.136.23.56:80 221.130.177.101:43386 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.112:51601 TIME_WAIT tcp 0 0 120.136.23.94:80 220.181.94.215:53097 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.188.236:53203 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:62297 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:64345 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.115.105:36600 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1743 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:35107 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:61801 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.155:57641 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17204 CLOSING tcp 0 0 120.136.23.93:80 119.235.237.85:45355 TIME_WAIT tcp 0 0 120.136.23.56:80 217.212.224.182:45195 TIME_WAIT tcp 0 0 120.136.23.56:80 220.189.10.170:1556 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.102:35701 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1745 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1749 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1748 TIME_WAIT tcp 0 0 120.136.23.56:80 221.195.76.250:26635 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.239:58417 TIME_WAIT tcp 0 0 120.136.23.56:80 67.218.116.164:53370 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.236:56168 TIME_WAIT tcp 0 0 120.136.23.93:80 120.136.23.93:36947 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:16991 CLOSING tcp 0 305 120.136.23.56:80 59.58.149.147:1881 ESTABLISHED tcp 0 0 120.136.23.56:80 61.186.48.148:1405 ESTABLISHED tcp 0 0 120.136.23.56:80 123.125.66.46:26703 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4814 TIME_WAIT tcp 0 0 120.136.23.56:80 218.86.49.153:1698 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4813 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4810 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.236:60508 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4811 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:43991 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:52182 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4806 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:56024 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4805 TIME_WAIT tcp 0 0 120.136.23.56:80 222.89.251.167:2133 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48340 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:63543 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:39544 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:48066 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4822 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.113.253:55817 TIME_WAIT tcp 0 0 120.136.23.56:80 219.141.124.130:11316 FIN_WAIT2 tcp 0 0 120.136.23.56:80 222.84.58.254:4820 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4816 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.140:40743 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:60979 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29255 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4078 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29251 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4079 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29260 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.236:51379 TIME_WAIT tcp 0 0 120.136.23.56:80 114.237.16.26:1363 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29263 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.220:63106 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.101:45795 TIME_WAIT tcp 0 0 120.136.23.56:80 111.224.115.203:46315 ESTABLISHED tcp 0 0 120.136.23.56:80 66.249.69.5:35081 ESTABLISHED tcp 0 0 120.136.23.56:80 203.209.252.26:51590 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29268 LAST_ACK tcp 0 0 120.136.23.80:80 216.7.175.100:54555 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.38:47180 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:64467 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29265 LAST_ACK tcp 0 0 120.136.23.92:80 220.181.7.110:46593 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29276 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4080 TIME_WAIT tcp 0 0 120.136.23.56:80 117.36.231.149:4081 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50215 TIME_WAIT tcp 0 101505 120.136.23.56:80 111.166.41.15:1315 ESTABLISHED tcp 0 2332 120.136.23.56:80 221.180.12.66:29274 LAST_ACK tcp 0 0 120.136.23.56:80 222.84.58.254:4878 TIME_WAIT tcp 0 1 120.136.23.93:80 58.33.226.66:4715 FIN_WAIT1 tcp 0 0 120.136.23.56:80 222.84.58.254:4877 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17062 CLOSING tcp 0 2332 120.136.23.56:80 221.180.12.66:29280 LAST_ACK tcp 0 0 120.136.23.56:80 222.84.58.254:4874 TIME_WAIT tcp 0 0 120.136.23.93:80 124.115.0.28:59777 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4872 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4870 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50449 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4868 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.107:37579 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.114.238:34255 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.105:35530 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:43960 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.229:41667 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:52669 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.239:56779 TIME_WAIT tcp 1 16560 120.136.23.56:80 210.13.118.102:43675 CLOSE_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17084 CLOSING tcp 0 0 120.136.23.56:80 221.130.177.105:33501 TIME_WAIT tcp 0 0 120.136.23.93:80 123.116.230.132:9703 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:49414 TIME_WAIT tcp 0 0 120.136.23.56:80 220.168.66.48:3360 ESTABLISHED tcp 0 0 120.136.23.56:80 220.168.66.48:3361 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.168.66.48:3362 ESTABLISHED tcp 0 0 120.136.23.80:80 66.249.68.183:39813 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:51569 TIME_WAIT tcp 0 0 120.136.23.56:80 216.129.119.11:58377 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.229:41914 TIME_WAIT tcp 0 0 120.136.23.56:80 60.213.146.54:33921 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50287 TIME_WAIT tcp 0 0 120.136.23.56:80 61.150.84.6:2094 TIME_WAIT tcp 0 0 120.136.23.56:80 67.218.116.166:33262 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.101:38064 TIME_WAIT tcp 0 0 120.136.23.56:80 110.75.167.223:39895 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48991 TIME_WAIT tcp 1 16560 120.136.23.56:80 210.13.118.102:61893 CLOSE_WAIT tcp 0 0 120.136.23.93:80 61.152.250.144:42832 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.174:37484 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:63403 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:62121 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.155:62189 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.80:60303 TIME_WAIT tcp 0 363 120.136.23.56:80 123.89.153.157:39067 ESTABLISHED tcp 0 0 127.0.0.1:80 127.0.0.1:49406 TIME_WAIT tcp 0 0 120.136.23.92:80 66.249.65.226:61423 TIME_WAIT tcp 0 0 120.136.23.56:80 122.136.173.33:19652 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29243 LAST_ACK tcp 0 0 120.136.23.56:80 122.136.173.33:19653 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5061 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.179.90:51318 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5060 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:54333 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5062 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.229:42547 ESTABLISHED tcp 0 0 120.136.23.56:80 123.125.66.135:39557 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5057 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17012 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17013 ESTABLISHED tcp 0 0 120.136.23.93:80 222.190.105.186:4641 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5059 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17014 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64078 ESTABLISHED tcp 0 0 120.136.23.56:80 122.86.41.132:5058 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17015 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64079 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17016 ESTABLISHED tcp 0 0 120.136.23.56:80 67.195.113.224:53092 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5065 LAST_ACK tcp 0 0 120.136.23.56:80 122.86.41.132:5064 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5067 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5066 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:58200 TIME_WAIT tcp 0 27544 120.136.23.56:80 124.160.125.8:8189 LAST_ACK tcp 0 0 120.136.23.56:80 123.125.66.27:30477 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:60019 TIME_WAIT tcp 0 0 120.136.23.56:80 60.169.49.238:64080 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.181.94.229:37673 TIME_WAIT tcp 0 26136 120.136.23.56:80 60.169.49.238:64081 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17002 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64082 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64083 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64084 FIN_WAIT2 tcp 0 0 120.136.23.56:80 60.169.49.238:64085 FIN_WAIT2 tcp 0 0 120.136.23.56:80 219.131.92.53:4084 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4085 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4086 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:42269 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56911 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56910 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4081 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:34606 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4082 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:25451 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4083 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:55875 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:51522 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49650 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4088 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4089 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18753 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18752 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18755 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.2:43954 ESTABLISHED tcp 0 0 120.136.23.56:80 124.224.63.144:18754 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:48903 TIME_WAIT tcp 0 0 120.136.23.56:80 121.0.29.194:61655 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56915 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56914 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:16247 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56913 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:59909 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:48389 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56912 TIME_WAIT tcp 0 0 120.136.23.93:80 222.190.105.186:4635 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.106:44326 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1812 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1810 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.104:36898 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:39033 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:58229 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1822 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1820 TIME_WAIT tcp 0 0 120.136.23.56:80 121.206.183.172:2214 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.181.94.221:54341 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1818 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18751 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18750 TIME_WAIT tcp 0 0 120.136.23.56:80 61.177.143.210:4226 TIME_WAIT tcp 0 0 120.136.23.56:80 116.9.9.250:55700 TIME_WAIT tcp 0 39599 120.136.23.93:80 125.107.166.221:3083 ESTABLISHED tcp 0 0 120.136.23.56:80 120.86.215.180:62554 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:48442 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34199 TIME_WAIT tcp 0 69227 120.136.23.93:80 125.107.166.221:3084 ESTABLISHED tcp 0 0 120.136.23.56:80 220.181.94.231:53605 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34196 TIME_WAIT tcp 0 0 120.136.23.56:80 120.86.215.180:62556 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34203 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.104:40252 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34202 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18731 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34201 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34200 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49538 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.57:49229 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18734 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34204 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2517 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:59728 TIME_WAIT tcp 0 0 120.136.23.56:80 116.20.61.208:50598 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5031 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5030 TIME_WAIT tcp 0 0 120.136.23.56:80 220.191.255.196:46290 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5037 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5036 LAST_ACK tcp 0 0 120.136.23.80:80 115.56.48.140:38058 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5039 TIME_WAIT tcp 0 0 120.136.23.80:80 115.56.48.140:38057 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5038 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:45862 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5033 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5032 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5034 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49582 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:38777 TIME_WAIT tcp 0 0 120.136.23.56:80 123.125.66.15:27007 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.98:59848 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5040 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:14651 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:58495 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2765 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5053 TIME_WAIT tcp 0 0 120.136.23.56:80 120.86.215.180:62578 ESTABLISHED tcp 0 0 120.136.23.56:80 202.160.179.58:36715 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5048 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:4889 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:1995 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49501 TIME_WAIT tcp 0 12270 120.136.23.56:80 119.12.4.49:49551 ESTABLISHED tcp 0 6988 120.136.23.56:80 119.12.4.49:49550 ESTABLISHED tcp 0 0 120.136.23.56:80 66.249.67.106:60516 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.179.76:56301 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.178.41:32907 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:24811 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.155:35617 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:50081 TIME_WAIT tcp 0 3650 120.136.23.56:80 119.12.4.49:49555 ESTABLISHED tcp 0 0 120.136.23.56:80 116.9.9.250:55632 TIME_WAIT tcp 0 4590 120.136.23.56:80 119.12.4.49:49554 ESTABLISHED tcp 0 823 120.136.23.56:80 119.12.4.49:49553 ESTABLISHED tcp 0 778 120.136.23.56:80 119.12.4.49:49552 ESTABLISHED tcp 0 31944 120.136.23.93:80 222.67.49.170:52229 ESTABLISHED tcp 0 0 120.136.23.93:80 219.219.127.2:44661 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:38602 TIME_WAIT tcp 0 0 120.136.23.56:80 61.177.143.210:4208 TIME_WAIT tcp 0 0 120.136.23.56:80 117.23.111.2:3297 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2079 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.49:44133 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:38627 TIME_WAIT tcp 0 660 120.136.23.56:80 113.16.37.24:62908 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.231:62850 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:33423 TIME_WAIT tcp 0 0 120.136.23.56:80 216.129.119.40:53331 TIME_WAIT tcp 0 0 120.136.23.56:80 116.248.65.32:2580 ESTABLISHED tcp 0 0 120.136.23.56:80 61.177.143.210:4199 TIME_WAIT tcp 0 0 120.136.23.93:80 125.107.166.221:3052 TIME_WAIT tcp 0 0 120.136.23.56:80 216.7.175.100:36933 TIME_WAIT tcp 0 1 120.136.23.56:80 183.35.149.94:2414 FIN_WAIT1 tcp 0 26963 120.136.23.56:80 124.160.125.8:8274 LAST_ACK tcp 0 0 120.136.23.93:80 61.153.27.172:16350 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:64907 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4116 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:32937 TIME_WAIT tcp 0 0 120.136.23.56:80 218.59.137.178:52731 FIN_WAIT2 tcp 0 0 120.136.23.56:80 123.125.66.53:31474 ESTABLISHED tcp 0 8950 120.136.23.56:80 221.194.136.245:21574 ESTABLISHED tcp 0 0 120.136.23.56:80 216.7.175.100:36922 TIME_WAIT tcp 0 0 120.136.23.56:80 216.7.175.100:36923 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.106:41386 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:62681 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:1639 ESTABLISHED tcp 0 0 120.136.23.56:80 219.131.92.53:4103 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:44007 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:15026 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.125:59521 TIME_WAIT tcp 0 660 120.136.23.56:80 113.16.37.24:62921 FIN_WAIT1 tcp 0 0 120.136.23.56:80 220.181.94.229:54767 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4148 ESTABLISHED tcp 0 0 120.136.23.93:80 202.104.103.210:2423 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4149 ESTABLISHED tcp 0 0 120.136.23.56:80 219.131.

  Read the article

• debian lenny xen bridge networking problem

  - by Sasha

  DomU isn't talking to the world, but it talks to Dom0. Here are the tests that I made: Dom0 (external networking is working): ping 188.40.96.238 #Which is Domu's ip PING 188.40.96.238 (188.40.96.238) 56(84) bytes of data. 64 bytes from 188.40.96.238: icmp_seq=1 ttl=64 time=0.092 ms DomU: ping 188.40.96.215 #Which is Dom0's ip PING 188.40.96.215 (188.40.96.215) 56(84) bytes of data. 64 bytes from 188.40.96.215: icmp_seq=1 ttl=64 time=0.045 ms ping 188.40.96.193 #Which is the gateway - fail PING 188.40.96.193 (188.40.96.193) 56(84) bytes of data. ^C --- 188.40.96.193 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1013ms The system is debian lenny with a normal setup. Here is my configs: uname -a Linux green0 2.6.26-2-xen-686 #1 SMP Wed Aug 19 08:47:57 UTC 2009 i686 GNU/Linux cat /etc/xen/green1.cfg |grep -v '#' kernel = '/boot/vmlinuz-2.6.26-2-xen-686' ramdisk = '/boot/initrd.img-2.6.26-2-xen-686' memory = '2000' root = '/dev/xvda2 ro' disk = [ 'file:/home/xen/domains/green1/swap.img,xvda1,w', 'file:/home/xen/domains/green1/disk.img,xvda2,w', ] name = 'green1' vif = [ 'ip=188.40.96.238,mac=00:16:3E:1F:C4:CC' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' ifconfig eth0 Link encap:Ethernet HWaddr 00:24:21:ef:2f:86 inet addr:188.40.96.215 Bcast:188.40.96.255 Mask:255.255.255.192 inet6 addr: fe80::224:21ff:feef:2f86/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3296 errors:0 dropped:0 overruns:0 frame:0 TX packets:2204 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:262717 (256.5 KiB) TX bytes:330465 (322.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) peth0 Link encap:Ethernet HWaddr 00:24:21:ef:2f:86 inet6 addr: fe80::224:21ff:feef:2f86/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:3407 errors:0 dropped:657431448 overruns:0 frame:0 TX packets:2291 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:319941 (312.4 KiB) TX bytes:338423 (330.4 KiB) Interrupt:16 Base address:0x8000 vif2.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:27 errors:0 dropped:0 overruns:0 frame:0 TX packets:151 errors:0 dropped:33 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:1164 (1.1 KiB) TX bytes:20974 (20.4 KiB) ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: peth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:24:21:ef:2f:86 brd ff:ff:ff:ff:ff:ff inet6 fe80::224:21ff:feef:2f86/64 scope link valid_lft forever preferred_lft forever 4: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 5: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 7: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 8: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 9: veth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 10: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 11: veth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 12: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:21:ef:2f:86 brd ff:ff:ff:ff:ff:ff inet 188.40.96.215/26 brd 188.40.96.255 scope global eth0 inet6 fe80::224:21ff:feef:2f86/64 scope link valid_lft forever preferred_lft forever 14: vif2.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32 link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff inet6 fe80::fcff:ffff:feff:ffff/64 scope link valid_lft forever preferred_lft forever brctl show bridge name bridge id STP enabled interfaces eth0 8000.002421ef2f86 no peth0 vif2.0 ip r l Dom0: 188.40.96.192/26 dev eth0 proto kernel scope link src 188.40.96.215 default via 188.40.96.193 dev eth0 DomU: 188.40.96.192/26 dev eth0 proto kernel scope link src 188.40.96.238 default via 188.40.96.193 dev eth0

  Read the article

• Route additional network through Sonicwall site-to-site VPN

  - by Brandon

  I have a sonicwall site to site vpn. At one of the sites there is another Cisco vpn to another site. I need to route the traffic for the cisco vpn through the site to site from the other sonicwall site. Site A - 10.10.0.0 /16 network Site B - 192.168.1.0 /24 Sonicwall, A cisco vpn is on 192.168.1.226 address and has routes the 10.10.0.0 network to Site A. Site C - 192.168.2.0 /24 Sonicwall Site A-B VPN is working Site B-C VPN is working I need to get Site C to transmit the 10.10.0.0 traffic over the VPN to site B and then out the Cisco device.

  Read the article

• Trouble connecting a Ubuntu system to IPv6 tunnel over NAT

  - by John Millikin

  I'm trying to set up an IPv6 tunnel, via Hurricane Electric's tunnel-broker service. I've configured my system using their example commands: # $ipv4a = tunnel server's IPv4 IP # $ipv4b = user's IPv4 IP # $ipv6a = tunnel server's side of point-to-point /64 allocation # $ipv6b = user's side of point-to-point /64 allocation ip tunnel add he-ipv6 mode sit remote $ipv4a local $ipv4b ttl 255 ip link set he-ipv6 up ip addr add $ipv6b dev he-ipv6 ip route add ::/0 dev he-ipv6 And have configured my desktop to be in my NAT router's DMZ. The router is running Tomato firmware. But I can't ping any IPv6 services: $ ping6 -I he-ipv6 '2001:470:1f04:454::1' PING 2001:470:1f04:454::1(2001:470:1f04:454::1) from 2001:470:1f04:454::2 he-ipv6: 56 data bytes From 2001:470:1f04:454::2 icmp_seq=1 Destination unreachable: Address unreachable From 2001:470:1f04:454::2 icmp_seq=2 Destination unreachable: Address unreachable I can ping my local address: $ ping6 -I he-ipv6 '2001:470:1f04:454::2' PING 2001:470:1f04:454::2(2001:470:1f04:454::2) from 2001:470:1f04:454::2 he-ipv6: 56 data bytes 64 bytes from 2001:470:1f04:454::2: icmp_seq=1 ttl=64 time=0.037 ms 64 bytes from 2001:470:1f04:454::2: icmp_seq=2 ttl=64 time=0.039 ms I don't know much about routing, but results I found online suggested the output of ip -6 route and ip addr could be useful: $ ip -6 route 2001:470:1f04:454::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev virbr0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295 default dev he-ipv6 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295 $ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:1c:c0:a1:98:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1 inet6 fe80::21c:c0ff:fea1:98b2/64 scope link valid_lft forever preferred_lft forever 3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 36:4c:33:ab:0d:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 inet6 fe80::344c:33ff:feab:dc6/64 scope link valid_lft forever preferred_lft forever 4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:76:62:6e:65:74 brd ff:ff:ff:ff:ff:ff 5: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 7e:29:5e:7c:ba:93 brd ff:ff:ff:ff:ff:ff 6: sit0: <NOARP> mtu 1480 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.0 7: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN link/sit 24.130.225.239 peer 72.52.104.74 inet6 2001:470:1f04:454::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1882:e1ef/128 scope link valid_lft forever preferred_lft forever

  Read the article

• VPN IP Routing - slow connections

  - by dannymcc

  UPDATE: Router error logs show: LCP Time-out 0 I'm not sure how to correct this. The Lan-to-Lan profiles are set to -1 Idle Timeout (for the remote branch). I have a PPTP VPN running between two Draytek 2820 routers. They are setup that one dials out to the other one. Main Practice - 192.168.1.0/24 Branch - 192.168.3.0/24 I have then set (on the Branch) router the following route: 192.168.1.0/24 If I then request a server running on 192.168.1.1 from the Branch, it correctly routes through VPN tunnel. If I request the branch server at 192.168.3.1 it correctly routes to the local server without using the VPN tunnel. I have temporarily disabled the firewall on both routers, and made sure that QoS is disabled. The Main Practice internet connection is ~30mb down / ~10mb up, and the Branch connection is ~5mb down / ~2mb up. Anything over the VPN tunnel runs pretty slowly (VNC, Remote Desktop and Terminal Emulators). However, if I dial using the Windows VPN wizard, creating a connection from the laptop to the Main Practice - everything runs quickly. I'm looking for possible causes, and/or ways of further diagnosing the issue. Any help would be greatly appreciated! UPDATE: In summary, when I connect within the Branch and try and access a host that's within the Main Practice it works, but slowly. If I then dial the VPN on my Windows 7 laptop whilst still connected to the Branch network, it's fast. Main Practice Branch Practice Routing Table from Branch Router Key: C - connected, S - static, R - RIP, * - default, ~ - private * 0.0.0.0/ 0.0.0.0 via 126.256.126.103 WAN2 C~ 192.168.1.99/ 255.255.255.255 directly connected VPN-1 S~ 192.168.1.0/ 255.255.255.0 via 192.168.1.99 VPN-1 S~ 192.168.2.0/ 255.255.255.0 via 192.168.1.99 VPN-1 C~ 192.168.3.0/ 255.255.255.0 directly connected LAN2 C 126.256.126.103/ 255.255.255.224 directly connected WAN2 Routing Table from Main Practice Key: C - connected, S - static, R - RIP, * - default, ~ - private * 0.0.0.0/ 0.0.0.0 via 81.139.64.1, WAN2 S 81.137.176.1/ 255.255.255.255 via 81.137.176.1, WAN2 * 81.139.64.1/ 255.255.255.255 via 81.139.64.1, WAN2 C~ 192.168.1.204/ 255.255.255.255 is directly connected, VPN C~ 192.168.1.0/ 255.255.255.0 is directly connected, LAN S~ 192.168.2.0/ 255.255.255.0 via 192.168.1.204, VPN S~ 192.168.3.0/ 255.255.255.0 via 192.168.1.203, VPN Connection Details (from Branch Router) Connection Details (from Main Practice Router) IPERF.exe Output

  Read the article

• Unclear pricing of Windows Azure

  - by Dirk

  How do you people think about the Windows Azure pricing model and the way it is presented to the user? I just found out that Azure keeps charging hours for STOPPED instances. I just received a bill from more than 100 euro for 3 STOPPED instances (not) running "HelloAzure". I the past I also played around with Amazon Web Services. Amazon doesn't charge for stopped instances. I was wondering: "Should I have known this before, or is Microsoft doing a bad job in clear communication in the pricing model?" Quote from http://www.microsoft.com/windowsazure/pricing/ : Compute time, measured in service hours: Windows Azure compute hours are charged only for when your application is deployed. When developing and testing your application, developers will want to remove the compute instances that are not being used to minimize compute hour billing. Partial compute hours are billed as full hours. I read this, so I stopped all instances after a few hours playing around. Now it seems I should have deleted them, not just "stopped". Strictly speaking, all depends on the definition of the word "deployed". If you upload an application, but it is not running, can it still be regarded as being "deployed"? May be, but when you read this for the first time, with AWS experience in mind, I don't think it's 100% clear what this means. Technically speaking, an uploaded application only uses (read: should only use / needs only) a few MB harddrive space. It doesn't require any CPU time. If Azure wants to reserve CPU's for not running instances.. well, that's Azure's choice, not mine. I don't want to spread a hate campaign at all, but I do want to know how people think about this subject. Should Microsoft be more clear about their pricing model or do you think it's clear enough? Second question: did anyone got refunded for a similar case? Thanks in advance! UPDATE 27-01-2011 I sent an email to customer support a few days ago, but I guess that didn't reach anu human being because I didn't hear anything from it. So, I made a telephone call today with a Dutch customer support representative (I live in Holland). She totally understood the problem and she's trying to get a refund for me. However, she mentioned that "usually these refund requests are denied", but she's going to try. She also mentioned that I'm not the first one with this (or similar) problem. UPDATE 28-01-2011 I just received a phonecall from Microsoft support. The lady told me some good news: the money will refunded. However, the invoice has not been made yet, and my creditcard will first be chardged, after which it will be refunded, but hey, that's no problem for me! I'm glad the way it's solved! Thanks everybody!

  Read the article

• Proxy arp and 1:1 NAT

  - by daniel4er

  I have a Linux router with 2 NICs doing masquerade from network 192.168.0.0/24 to an ADSL router. users <----> NIC A [router] NIC B <----> INTERNET Now I'm experimenting with proxy arp on the NIC A to intercept all the IP requests in the network. I have a pool of addresses in the 192.168.0.0/24 network for this users. How can I translate, saythe IP10.0.0.64to192.168.0.64` in order to grant it internet access? I have already tried SNAT - DNAT, even I have written a NFQUEUE app to spoof the IP address with no luck.

  Read the article

• Configuring VLAN's on two HP procurve switches

  - by pan

  Trying to route a new ISP (Microwave link) from one of my out buildings to my computer room and hence my firewall. Old ISP came direct into firewall. In the outbuilding the Microwave modem connects with cat5 to HP Procurve 2524 switch. Because this ISP is coming through my internal network, I plan on using a new vlan called "airspeed" only for this ISP traffic. Up until now I've just been using the Default_vlan on both HP switches (4108 + 2524). So far I've been unable to ping from my laptop to the ISP modem both of which are on the new vlan 2 ("Airspeed"). No traffic needs to cross from vlan 2 to vlan 1 so I've left the ports as untagged. I've used the subnet provide from my ISP as the new vlan 2 subnet. Can anybody see what I'm doing wrong here? I've added the configuration of both switch below. Rough diagram: Microwave modem (Gateway IP 77.75.00.49) | HP 2524 switch (port 24) | HP 2524 switch fibre link | HP 4108GL switch fibre link | HP 4108GL switch (port D1) | Laptop configured with IP 77.75.00.50 (for testing but will be connected to firewall) And my 4108GL config: ; J4865A Configuration Editor; Created on release #G.07.21 hostname "HP ProCurve Switch 4108GL" cdp run module 1 type J4864A module 2 type J4862B module 3 type J4862B module 4 type J4862B ip default-gateway 128.1.146.50 snmp-server community "public" Unrestricted snmp-server host 128.1.146.51 "public" Not-INFO snmp-server host 128.1.146.38 "public" vlan 1 name "DEFAULT_VLAN" untagged A1-A3,B1-B24,C1-C24,D2-D24 ip address 128.1.146.203 255.255.0.0 no untagged D1 exit vlan 2 name "Airspeed" untagged D1 ip address 77.75.00.51 255.255.255.248 exit Finally my 2524 config: ; J4813A Configuration Editor; Created on release #F.04.08 hostname "HP ProCurve Switch 2524" cdp run ip default-gateway 0.0.0.0 snmp-server community "public" Unrestricted snmp-server host 128.1.146.51 "public" Not-INFO snmp-server host 128.1.146.51 "public" snmp-server host 128.1.146.38 "public" vlan 1 name "DEFAULT_VLAN" untagged 1-23,25-26 no untagged 24 ip address 128.1.146.204 255.255.0.0 exit vlan 2 name "Airspeed" untagged 24 ip address 77.75.00.51 255.255.255.248 exit no aaa port-access authenticator active

  Read the article

• Connecting to a remote server through OpenVPN when local network subnet conflicts with remote network's subnet

  - by John Russell

  After connecting to a remote location via OpenVPN, I am trying to access a server on a network that exists on a subnet such as 10.0.1.0/24. However, the network I am trying to access this remote server from is on the same subnet: 10.0.1.0/24. I am unable to connect to my remote server via typing in its IP because of this conflict. I am unable to even access the public internet while connected to the VPN. Does anyone know how to mitigate this issue? I have access to the OpenVPN Access Server.

  Read the article

• Linux - Only first virtual interface can ping external gateway

  - by husvar

  I created 3 virtual interfaces with different mac addresses all linked to the same physical interface. I see that they successfully arp for the gw and they can ping (the request is coming in the packet capture in wireshark). However the ping utility does not count the responses. Does anyone knows the issue? I am running Ubuntu 14.04 in a VmWare. root@ubuntu:~# ip link sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:bc:fc:8b brd ff:ff:ff:ff:ff:ff root@ubuntu:~# ip addr sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:bc:fc:8b brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:febc:fc8b/64 scope link valid_lft forever preferred_lft forever root@ubuntu:~# ip route sh root@ubuntu:~# ip link add link eth0 eth0.1 addr 00:00:00:00:00:11 type macvlan root@ubuntu:~# ip link add link eth0 eth0.2 addr 00:00:00:00:00:22 type macvlan root@ubuntu:~# ip link add link eth0 eth0.3 addr 00:00:00:00:00:33 type macvlan root@ubuntu:~# ip -4 link sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:bc:fc:8b brd ff:ff:ff:ff:ff:ff 18: eth0.1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 00:00:00:00:00:11 brd ff:ff:ff:ff:ff:ff 19: eth0.2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 00:00:00:00:00:22 brd ff:ff:ff:ff:ff:ff 20: eth0.3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 00:00:00:00:00:33 brd ff:ff:ff:ff:ff:ff root@ubuntu:~# ip -4 addr sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever root@ubuntu:~# ip -4 route sh root@ubuntu:~# dhclient -v eth0.1 Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0.1/00:00:00:00:00:11 Sending on LPF/eth0.1/00:00:00:00:00:11 Sending on Socket/fallback DHCPDISCOVER on eth0.1 to 255.255.255.255 port 67 interval 3 (xid=0x568eac05) DHCPREQUEST of 192.168.1.145 on eth0.1 to 255.255.255.255 port 67 (xid=0x568eac05) DHCPOFFER of 192.168.1.145 from 192.168.1.254 DHCPACK of 192.168.1.145 from 192.168.1.254 bound to 192.168.1.145 -- renewal in 1473 seconds. root@ubuntu:~# dhclient -v eth0.2 Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0.2/00:00:00:00:00:22 Sending on LPF/eth0.2/00:00:00:00:00:22 Sending on Socket/fallback DHCPDISCOVER on eth0.2 to 255.255.255.255 port 67 interval 3 (xid=0x21e3114e) DHCPREQUEST of 192.168.1.146 on eth0.2 to 255.255.255.255 port 67 (xid=0x21e3114e) DHCPOFFER of 192.168.1.146 from 192.168.1.254 DHCPACK of 192.168.1.146 from 192.168.1.254 bound to 192.168.1.146 -- renewal in 1366 seconds. root@ubuntu:~# dhclient -v eth0.3 Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0.3/00:00:00:00:00:33 Sending on LPF/eth0.3/00:00:00:00:00:33 Sending on Socket/fallback DHCPDISCOVER on eth0.3 to 255.255.255.255 port 67 interval 3 (xid=0x11dc5f03) DHCPREQUEST of 192.168.1.147 on eth0.3 to 255.255.255.255 port 67 (xid=0x11dc5f03) DHCPOFFER of 192.168.1.147 from 192.168.1.254 DHCPACK of 192.168.1.147 from 192.168.1.254 bound to 192.168.1.147 -- renewal in 1657 seconds. root@ubuntu:~# ip -4 link sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:bc:fc:8b brd ff:ff:ff:ff:ff:ff 18: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 00:00:00:00:00:11 brd ff:ff:ff:ff:ff:ff 19: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 00:00:00:00:00:22 brd ff:ff:ff:ff:ff:ff 20: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 00:00:00:00:00:33 brd ff:ff:ff:ff:ff:ff root@ubuntu:~# ip -4 addr sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 18: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default inet 192.168.1.145/24 brd 192.168.1.255 scope global eth0.1 valid_lft forever preferred_lft forever 19: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default inet 192.168.1.146/24 brd 192.168.1.255 scope global eth0.2 valid_lft forever preferred_lft forever 20: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default inet 192.168.1.147/24 brd 192.168.1.255 scope global eth0.3 valid_lft forever preferred_lft forever root@ubuntu:~# ip -4 route sh default via 192.168.1.254 dev eth0.1 192.168.1.0/24 dev eth0.1 proto kernel scope link src 192.168.1.145 192.168.1.0/24 dev eth0.2 proto kernel scope link src 192.168.1.146 192.168.1.0/24 dev eth0.3 proto kernel scope link src 192.168.1.147 root@ubuntu:~# arping -c 5 -I eth0.1 192.168.1.254 ARPING 192.168.1.254 from 192.168.1.145 eth0.1 Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 6.936ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 2.986ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 0.654ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 5.137ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 2.426ms Sent 5 probes (1 broadcast(s)) Received 5 response(s) root@ubuntu:~# arping -c 5 -I eth0.2 192.168.1.254 ARPING 192.168.1.254 from 192.168.1.146 eth0.2 Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 5.665ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 3.753ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 16.500ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 3.287ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 32.438ms Sent 5 probes (1 broadcast(s)) Received 5 response(s) root@ubuntu:~# arping -c 5 -I eth0.3 192.168.1.254 ARPING 192.168.1.254 from 192.168.1.147 eth0.3 Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 4.422ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 2.429ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 2.321ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 40.423ms Unicast reply from 192.168.1.254 [58:98:35:57:a0:70] 2.268ms Sent 5 probes (1 broadcast(s)) Received 5 response(s) root@ubuntu:~# tcpdump -n -i eth0.1 -v & [1] 5317 root@ubuntu:~# ping -c5 -q -I eth0.1 192.168.1.254 PING 192.168.1.254 (192.168.1.254) from 192.168.1.145 eth0.1: 56(84) bytes of data. tcpdump: listening on eth0.1, link-type EN10MB (Ethernet), capture size 65535 bytes 13:18:37.612558 IP (tos 0x0, ttl 64, id 2595, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.145 > 192.168.1.254: ICMP echo request, id 5318, seq 2, length 64 13:18:37.618864 IP (tos 0x68, ttl 64, id 14493, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.145: ICMP echo reply, id 5318, seq 2, length 64 13:18:37.743650 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 13:18:38.134997 IP (tos 0x0, ttl 128, id 23547, offset 0, flags [none], proto UDP (17), length 229) 192.168.1.86.138 > 192.168.1.255.138: NBT UDP PACKET(138) 13:18:38.614580 IP (tos 0x0, ttl 64, id 2596, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.145 > 192.168.1.254: ICMP echo request, id 5318, seq 3, length 64 13:18:38.793479 IP (tos 0x68, ttl 64, id 14495, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.145: ICMP echo reply, id 5318, seq 3, length 64 13:18:39.151282 IP6 (class 0x68, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5a98:35ff:fe57:e070 > ff02::1:ff6b:e9b4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:818:d812:da00:8ae3:abff:fe6b:e9b4 source link-address option (1), length 8 (1): 58:98:35:57:a0:70 13:18:39.615612 IP (tos 0x0, ttl 64, id 2597, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.145 > 192.168.1.254: ICMP echo request, id 5318, seq 4, length 64 13:18:39.746981 IP (tos 0x68, ttl 64, id 14496, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.145: ICMP echo reply, id 5318, seq 4, length 64 --- 192.168.1.254 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4008ms rtt min/avg/max/mdev = 2.793/67.810/178.934/73.108 ms root@ubuntu:~# killall tcpdump >> /dev/null 2>&1 9 packets captured 12 packets received by filter 0 packets dropped by kernel [1]+ Done tcpdump -n -i eth0.1 -v root@ubuntu:~# tcpdump -n -i eth0.2 -v & [1] 5320 root@ubuntu:~# ping -c5 -q -I eth0.2 192.168.1.254 PING 192.168.1.254 (192.168.1.254) from 192.168.1.146 eth0.2: 56(84) bytes of data. tcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 65535 bytes 13:18:41.536874 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 58:98:35:57:a0:70, length 46 13:18:41.536933 IP (tos 0x0, ttl 64, id 2599, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.146 > 192.168.1.254: ICMP echo request, id 5321, seq 1, length 64 13:18:41.539255 IP (tos 0x68, ttl 64, id 14507, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.146: ICMP echo reply, id 5321, seq 1, length 64 13:18:42.127715 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 13:18:42.511725 IP (tos 0x0, ttl 64, id 2600, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.146 > 192.168.1.254: ICMP echo request, id 5321, seq 2, length 64 13:18:42.514385 IP (tos 0x68, ttl 64, id 14527, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.146: ICMP echo reply, id 5321, seq 2, length 64 13:18:42.743856 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 13:18:43.511727 IP (tos 0x0, ttl 64, id 2601, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.146 > 192.168.1.254: ICMP echo request, id 5321, seq 3, length 64 13:18:43.513768 IP (tos 0x68, ttl 64, id 14528, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.146: ICMP echo reply, id 5321, seq 3, length 64 13:18:43.637598 IP (tos 0x0, ttl 128, id 23551, offset 0, flags [none], proto UDP (17), length 225) 192.168.1.86.17500 > 255.255.255.255.17500: UDP, length 197 13:18:43.641185 IP (tos 0x0, ttl 128, id 23552, offset 0, flags [none], proto UDP (17), length 225) 192.168.1.86.17500 > 192.168.1.255.17500: UDP, length 197 13:18:43.641201 IP (tos 0x0, ttl 128, id 23553, offset 0, flags [none], proto UDP (17), length 225) 192.168.1.86.17500 > 255.255.255.255.17500: UDP, length 197 13:18:43.743890 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 13:18:44.510758 IP (tos 0x0, ttl 64, id 2602, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.146 > 192.168.1.254: ICMP echo request, id 5321, seq 4, length 64 13:18:44.512892 IP (tos 0x68, ttl 64, id 14538, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.146: ICMP echo reply, id 5321, seq 4, length 64 13:18:45.510794 IP (tos 0x0, ttl 64, id 2603, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.146 > 192.168.1.254: ICMP echo request, id 5321, seq 5, length 64 13:18:45.519701 IP (tos 0x68, ttl 64, id 14539, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.254 > 192.168.1.146: ICMP echo reply, id 5321, seq 5, length 64 13:18:49.287554 IP6 (class 0x68, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5a98:35ff:fe57:e070 > ff02::1:ff6b:e9b4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:818:d812:da00:8ae3:abff:fe6b:e9b4 source link-address option (1), length 8 (1): 58:98:35:57:a0:70 13:18:50.013463 IP (tos 0x0, ttl 255, id 50737, offset 0, flags [DF], proto UDP (17), length 73) 192.168.1.146.5353 > 224.0.0.251.5353: 0 [2q] PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (45) 13:18:50.218874 IP6 (class 0x68, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5a98:35ff:fe57:e070 > ff02::1:ff6b:e9b4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:818:d812:da00:8ae3:abff:fe6b:e9b4 source link-address option (1), length 8 (1): 58:98:35:57:a0:70 13:18:51.129961 IP6 (class 0x68, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5a98:35ff:fe57:e070 > ff02::1:ff6b:e9b4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:818:d812:da00:8ae3:abff:fe6b:e9b4 source link-address option (1), length 8 (1): 58:98:35:57:a0:70 13:18:52.197074 IP6 (hlim 255, next-header UDP (17) payload length: 53) 2001:818:d812:da00:200:ff:fe00:22.5353 > ff02::fb.5353: [udp sum ok] 0 [2q] PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (45) 13:18:54.128240 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 --- 192.168.1.254 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4000ms root@ubuntu:~# killall tcpdump >> /dev/null 2>&1 13:18:54.657731 IP6 (class 0x68, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5a98:35ff:fe57:e070 > ff02::1:ff6b:e9b4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:818:d812:da00:8ae3:abff:fe6b:e9b4 source link-address option (1), length 8 (1): 58:98:35:57:a0:70 13:18:54.743174 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.87 tell 192.168.1.86, length 46 25 packets captured 26 packets received by filter 0 packets dropped by kernel [1]+ Done tcpdump -n -i eth0.2 -v root@ubuntu:~# tcpdump -n -i eth0.3 icmp & [1] 5324 root@ubuntu:~# ping -c5 -q -I eth0.3 192.168.1.254 PING 192.168.1.254 (192.168.1.254) from 192.168.1.147 eth0.3: 56(84) bytes of data. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0.3, link-type EN10MB (Ethernet), capture size 65535 bytes 13:18:56.373434 IP 192.168.1.147 > 192.168.1.254: ICMP echo request, id 5325, seq 1, length 64 13:18:57.372116 IP 192.168.1.147 > 192.168.1.254: ICMP echo request, id 5325, seq 2, length 64 13:18:57.381263 IP 192.168.1.254 > 192.168.1.147: ICMP echo reply, id 5325, seq 2, length 64 13:18:58.371141 IP 192.168.1.147 > 192.168.1.254: ICMP echo request, id 5325, seq 3, length 64 13:18:58.373275 IP 192.168.1.254 > 192.168.1.147: ICMP echo reply, id 5325, seq 3, length 64 13:18:59.371165 IP 192.168.1.147 > 192.168.1.254: ICMP echo request, id 5325, seq 4, length 64 13:18:59.373259 IP 192.168.1.254 > 192.168.1.147: ICMP echo reply, id 5325, seq 4, length 64 13:19:00.371211 IP 192.168.1.147 > 192.168.1.254: ICMP echo request, id 5325, seq 5, length 64 13:19:00.373278 IP 192.168.1.254 > 192.168.1.147: ICMP echo reply, id 5325, seq 5, length 64 --- 192.168.1.254 ping statistics --- 5 packets transmitted, 1 received, 80% packet loss, time 4001ms rtt min/avg/max/mdev = 13.666/13.666/13.666/0.000 ms root@ubuntu:~# killall tcpdump >> /dev/null 2>&1 9 packets captured 10 packets received by filter 0 packets dropped by kernel [1]+ Done tcpdump -n -i eth0.3 icmp root@ubuntu:~# arp -n Address HWtype HWaddress Flags Mask Iface 192.168.1.254 ether 58:98:35:57:a0:70 C eth0.1 192.168.1.254 ether 58:98:35:57:a0:70 C eth0.2 192.168.1.254 ether 58:98:35:57:a0:70 C eth0.3

  Read the article

• Poor NFS Performance: OpenFiler

  - by Safin09

  Good Day Everyone, I have an issue with OpenFiler, a Linux-based operating that converts a computer system into a SAN/NAS appliance. Here is the problem. In my environment we have two Netapp Storevault 500 appliances that I normally perform backups to a NFS share. There are two backup cronjobs that use ghettoVCB to backup two groups of VM's. One group is a pool of 3 VMs. This takes 13 mins to complete. A second job that backups a pool of 5 VMs to a 2nd Storevault appliance which takes 2 hours. We then installed Openfiler on a old server that has 2 core Xeon processors. There is a software RAID 5 process in place. When performing the same backups to a NFS Openfiler share, the first backup job, which takes 13 mins, takes around 4 hours. The second backup job, which takes 2 hours, takes almost 10 hours to complete. This is unacceptable!!!! Especially considering the strain placed on the host ESX Server. I assumed that because of the software RAID 5, the overhead on the CPU explained the long backup times. I then installed Openfiler on a 2nd server, an IBM x306 machine which has a P4 Intel processor. This time no software RAID or any RAID at all. A single 750GB hard drive that contained the OS and the rest of the disk uses to backup VMs to a NFS share. I performed the first backup job of the pool of 3 VMs. This time the backup job took 1 and 1/2 hours to complete instead of 13 mins!!!!!!!!!! Is Openfiler simply poor at being an NFS Server!!!!!!!!!!!!! Has anyone else had these issues with Openfiler?

  Read the article

• Improving SAS multipath to JBOD performance on Linux

  - by user36825

  Hello all I'm trying to optimize a storage setup on some Sun hardware with Linux. Any thoughts would be greatly appreciated. We have the following hardware: Sun Blade X6270 2* LSISAS1068E SAS controllers 2* Sun J4400 JBODs with 1 TB disks (24 disks per JBOD) Fedora Core 12 2.6.33 release kernel from FC13 (also tried with latest 2.6.31 kernel from FC12, same results) Here's the datasheet for the SAS hardware: http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf It's using PCI Express 1.0a, 8x lanes. With a bandwidth of 250 MB/sec per lane, we should be able to do 2000 MB/sec per SAS controller. Each controller can do 3 Gb/sec per port and has two 4 port PHYs. We connect both PHYs from a controller to a JBOD. So between the JBOD and the controller we have 2 PHYs * 4 SAS ports * 3 Gb/sec = 24 Gb/sec of bandwidth, which is more than the PCI Express bandwidth. With write caching enabled and when doing big writes, each disk can sustain about 80 MB/sec (near the start of the disk). With 24 disks, that means we should be able to do 1920 MB/sec per JBOD. multipath { rr_min_io 100 uid 0 path_grouping_policy multibus failback manual path_selector "round-robin 0" rr_weight priorities alias somealias no_path_retry queue mode 0644 gid 0 wwid somewwid } I tried values of 50, 100, 1000 for rr_min_io, but it doesn't seem to make much difference. Along with varying rr_min_io I tried adding some delay between starting the dd's to prevent all of them writing over the same PHY at the same time, but this didn't make any difference, so I think the I/O's are getting properly spread out. According to /proc/interrupts, the SAS controllers are using a "IR-IO-APIC-fasteoi" interrupt scheme. For some reason only core #0 in the machine is handling these interrupts. I can improve performance slightly by assigning a separate core to handle the interrupts for each SAS controller: echo 2 /proc/irq/24/smp_affinity echo 4 /proc/irq/26/smp_affinity Using dd to write to the disk generates "Function call interrupts" (no idea what these are), which are handled by core #4, so I keep other processes off this core too. I run 48 dd's (one for each disk), assigning them to cores not dealing with interrupts like so: taskset -c somecore dd if=/dev/zero of=/dev/mapper/mpathx oflag=direct bs=128M oflag=direct prevents any kind of buffer cache from getting involved. None of my cores seem maxed out. The cores dealing with interrupts are mostly idle and all the other cores are waiting on I/O as one would expect. Cpu0 : 0.0%us, 1.0%sy, 0.0%ni, 91.2%id, 7.5%wa, 0.0%hi, 0.2%si, 0.0%st Cpu1 : 0.0%us, 0.8%sy, 0.0%ni, 93.0%id, 0.2%wa, 0.0%hi, 6.0%si, 0.0%st Cpu2 : 0.0%us, 0.6%sy, 0.0%ni, 94.4%id, 0.1%wa, 0.0%hi, 4.8%si, 0.0%st Cpu3 : 0.0%us, 7.5%sy, 0.0%ni, 36.3%id, 56.1%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 1.3%sy, 0.0%ni, 85.7%id, 4.9%wa, 0.0%hi, 8.1%si, 0.0%st Cpu5 : 0.1%us, 5.5%sy, 0.0%ni, 36.2%id, 58.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 5.0%sy, 0.0%ni, 36.3%id, 58.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 5.1%sy, 0.0%ni, 36.3%id, 58.5%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 : 0.1%us, 8.3%sy, 0.0%ni, 27.2%id, 64.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 : 0.1%us, 7.9%sy, 0.0%ni, 36.2%id, 55.8%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 : 0.0%us, 7.8%sy, 0.0%ni, 36.2%id, 56.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 : 0.0%us, 7.3%sy, 0.0%ni, 36.3%id, 56.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 : 0.0%us, 5.6%sy, 0.0%ni, 33.1%id, 61.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 : 0.1%us, 5.3%sy, 0.0%ni, 36.1%id, 58.5%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 : 0.0%us, 4.9%sy, 0.0%ni, 36.4%id, 58.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 : 0.1%us, 5.4%sy, 0.0%ni, 36.5%id, 58.1%wa, 0.0%hi, 0.0%si, 0.0%st Given all this, the throughput reported by running "dstat 10" is in the range of 2200-2300 MB/sec. Given the math above I would expect something in the range of 2*1920 ~= 3600+ MB/sec. Does anybody have any idea where my missing bandwidth went? Thanks!

  Read the article

• Resolving DNS queries for two disconnected, private, networks

  - by Mikeage

  I'm trying to setup two PCs (one Windows, one Linux, but my understanding is that this problem is more DNS and less OS) as follows: Home network: 192.168.1.0/24 VPN (via OpenVPN server not within the home network): 192.168.2.0/24 . I would like a PC on both networks to be able to access three different types of site: Internet addresses Addresses on the home network Addresses on the vpn However, I'm not sure how/which DNS servers to use. If I prioritize my home DNS server, I can resolve (1) and (2), but not (3). If I prioritize my VPN DNS server, I can't resolve addresses of type (2). Of course, looking up addresses via nslookup and explicitly setting the correct server works, so I know my local DNS servers are OK. Is there any way I can set up my PCs to fallback on the second DNS server if there is no response? Alternatively, is there any way I can tell different queries to go to different servers [maybe by setting up different subdomains; foo.local.something vs. bar.vpn.something]? Thanks

  Read the article

• Bonjour/mDNS Broadcast across subnets

  - by Matthew Savage

  I have just setup a new OSX Server in our office and verified that everything is working fine over our wired network (192.168.126.0/24). The problem that I am having is that our clients (Mac Laptops) are mainly connected via Wireless, which are running on a different subnet (192.168.1.0/24), and the mDNS Broadcast isn't reaching this subnet. The network configuration is somewhat foreign to myself (I don't manage the network in this location, but as of just recently the servers), however I don't believe there is any firewalls or routing rules between the two subnets which might cause the traffic to be rejected. I'm wondering if this is simply the mDNS broadcast not able to broadcast over the two different subnets (I'm still reading up on broadcast to understand it more) or there is something else which I might be able to try.

  Read the article

< Previous Page | 106 107 108 109 110 111 112 113 114 115 116 117  | Next Page >