I have been doing research on WAN acceleration for a while now. Unfortunately due to the cost I have been unable to get it installed in the network that I manage. So several months ago I started working on my own WAN accelerator as an open source project.
I recently finished a pre-alpha, and am moving forward with its development. I have setup a portal for it at http://www.opennop.org. The pre-alpha is entirely contained in a kernel module, and is limited to compression. The next release I am working on is a combination kernel module and user space service that does the optimizations. It also currently capable of compression of the application data within the TCP segment, but is also multi-threaded to increase performance.
The next feature I will be adding is block based data reduction. This will be a difficult feature to implement, but is one of the most beneficial in terms of increasing WAN performance.
Wednesday, April 28, 2010
Fun with a Smart-UPS 1400RMNET.
I got an old UPS its a Smart-UPS 1400RMNET. Its the type without a battery tray just an array of batteries that must be slid into the unit, and then connected.
This unit uses 4 batteries, but I didn't happen to have the wiring diagram so I was just connecting them how I thought they might have been connected. I thought they were wired in two parallel series giving the battery array a total of 24v, but longer run time. The unit made all kinds of horrid noise when I turned it on. So I tried a few different ways trying to get it to work.
I eventually found a picture of what the battery array should look like, and was able to make a wiring diagram for myself. I also found that the battery array should be 48v not 24v.
This unit uses 4 batteries, but I didn't happen to have the wiring diagram so I was just connecting them how I thought they might have been connected. I thought they were wired in two parallel series giving the battery array a total of 24v, but longer run time. The unit made all kinds of horrid noise when I turned it on. So I tried a few different ways trying to get it to work.
I eventually found a picture of what the battery array should look like, and was able to make a wiring diagram for myself. I also found that the battery array should be 48v not 24v.
Thursday, April 22, 2010
Intercepting IP packets using Netfilter hooks
Netfilter hooks are very useful when you wish to intercept, and modify IP packets inside a kernel module.
One great thing about using Netfilter hooks over say dev_add_pack() is that the bad L2 frames, and bad IP packets get filtered out earlier in the network stack so you only deal with good packets.
Now the whole point of the Netfilter hook is to customize what the kernel does with the packets received by the system so here is an example hook function. It simply does some checks to make sure the packet is a TCP packet, and then prints the IP, and port info if it is. You may also want to check for other traffic types such as UDP, or ICMP you should be able to figure that out.
Somewhere in your function you must tell the system what to do with the packet that is being processed. You have several options with what you do with the packet. They are.
My example hook function.
One thing to note about accessing the IP header, and TCP header fields. The data within most of them will be in a in a reversed order than the system is use to working with. To swap the "endianness" between host format, and network format use these function ntohs(), htons(), ntohs(), and ntohl().
So now that you have your hook function lets setup the hook. Its actually quite simple here is an example.
You can hook into five different points as the packets pass through the system. Good documentation can be found here about each of them. http://www.iptables.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html
Now in your module initialization function you need to register your hook.
You also need to unregister your hook in your module exit function.
One great thing about using Netfilter hooks over say dev_add_pack() is that the bad L2 frames, and bad IP packets get filtered out earlier in the network stack so you only deal with good packets.
Now the whole point of the Netfilter hook is to customize what the kernel does with the packets received by the system so here is an example hook function. It simply does some checks to make sure the packet is a TCP packet, and then prints the IP, and port info if it is. You may also want to check for other traffic types such as UDP, or ICMP you should be able to figure that out.
Somewhere in your function you must tell the system what to do with the packet that is being processed. You have several options with what you do with the packet. They are.
- NF_DROP Discard the packet.
- NF_ACCEPT Keep the packet.
- NF_STOLEN Forget about the packet.
- NF_QUEUE Queue packet for userspace.
- NF_REPEAT Call this hook function again.
My example hook function.
static unsigned int
myhook_func(unsigned int hooknum,
struct sk_buff **skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *)){
struct iphdr *iph = NULL;
struct tcphdr *tcph = NULL;
if ((skb != NULL) &&
((*skb)->pkt_type == PACKET_HOST) &&
((*skb)->protocol == htons(ETH_P_IP))){
iph = ip_hdr((*skb)); // access ip header.
/*
* yaple: Process only TCP segments.
*/
if ((iph->protocol == IPPROTO_TCP) ){
tcph = (struct tcphdr *)(skb_network_header((*skb)) + ip_hdrlen((*skb))); // access tcp header.
printk(KERN_ALERT "INFO: Source IP Address: %u.\n",iph->saddr);
printk(KERN_ALERT "INFO: Destination IP Address: %u.\n",iph->daddr);
printk(KERN_ALERT "INFO: Source Port: %u.\n",tcph->source);
printk(KERN_ALERT "INFO: Destination Port: %u.\n",tcph->dest);
}
}
return NF_ACCEPT; // Tells the system to accept the packet, and process the next one.
}
One thing to note about accessing the IP header, and TCP header fields. The data within most of them will be in a in a reversed order than the system is use to working with. To swap the "endianness" between host format, and network format use these function ntohs(), htons(), ntohs(), and ntohl().
So now that you have your hook function lets setup the hook. Its actually quite simple here is an example.
static struct nf_hook_ops my_hook = { // This is a Netfilter hook.
.hook = myhook_func, // Function that executes when a packet hits this hook.
.hooknum = NF_IP_FORWARD, // For routed traffic only.
.pf = PF_INET, // Only for IP packets.
.priority = NF_IP_PRI_FIRST, // My hook executes first.
};
You can hook into five different points as the packets pass through the system. Good documentation can be found here about each of them. http://www.iptables.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html
- NF_IP_PRE_ROUTING
- NF_IP_LOCAL_IN
- NF_IP_FORWARD
- NF_IP_POST_ROUTING
- NF_IP_LOCAL_OUT
Now in your module initialization function you need to register your hook.
nf_register_hook(&my_hook);
You also need to unregister your hook in your module exit function.
nf_unregister_hook(&my_hook);
Friday, April 9, 2010
Network Access Protection Unseen Issues
Anyone that has implemented NAP knows its not that difficult. Its much easier than it used to be to get IAS setup to support 802.1x network authentication, and it does health checks on the systems to make sure they are configured correctly. Now that sounds great, but its not so great when those health checks cause 50% of your desktops to spike 100% CPU usage for 3-7 minuets. That makes your users very unhappy.
Our users have never been happy with how slow the WAN is. Things got more vocal after we implemented NAP, and according to the network monitoring software the bandwidth was fine. Also every time we checked the PCs they would be running fine.
Well after a while someone finally noticed that the slowdown was happening right when the Offline Health Checks were running, and they always ran around the same time on these effected systems. So we watched one, and sure enough svchost.exe spiked to 100% for around 5 minuets.
Ok thats not helpful at all because tons of stuff runs under svchost.exe. So I download process explorer and launched it. We left it running on one of the effected PCs until it happened again about 60 minuets later.
So now we know what svchost.exe process was causing the issue, but sure enough this particular svchost.exe had all kinds of stuff running in it so we opened the "Threads" tab of this particular svchost.exe process, and waited for it again.
Finally identified the particular thread, and its associated file as wuaueng.dll. Well thats just the Windows Update service. So we checked its version 7.1.x.x, and compared it to a system that works fine, and it was 7.2.x.x oh look at that.
So I found this update http://support.microsoft.com/kb/949104, and after installing it on all the "slow" PCs they work fine.
Our users have never been happy with how slow the WAN is. Things got more vocal after we implemented NAP, and according to the network monitoring software the bandwidth was fine. Also every time we checked the PCs they would be running fine.
Well after a while someone finally noticed that the slowdown was happening right when the Offline Health Checks were running, and they always ran around the same time on these effected systems. So we watched one, and sure enough svchost.exe spiked to 100% for around 5 minuets.
Ok thats not helpful at all because tons of stuff runs under svchost.exe. So I download process explorer and launched it. We left it running on one of the effected PCs until it happened again about 60 minuets later.
So now we know what svchost.exe process was causing the issue, but sure enough this particular svchost.exe had all kinds of stuff running in it so we opened the "Threads" tab of this particular svchost.exe process, and waited for it again.
Finally identified the particular thread, and its associated file as wuaueng.dll. Well thats just the Windows Update service. So we checked its version 7.1.x.x, and compared it to a system that works fine, and it was 7.2.x.x oh look at that.
So I found this update http://support.microsoft.com/kb/949104, and after installing it on all the "slow" PCs they work fine.
Subscribe to:
Posts (Atom)