 Cool, thanks. Yeah, it's a little early on Sunday. Yeah, we're going to be rolling old school today with some ARP. So I know hacking ARP has been around for a bit. We're going to kind of go over some of the classic attacks and then a little bit of a twist on some of them. A little bit more effective here and there. Some of the tools that are out there that do things like ARP cache poisoning and stuff like that don't really take advantage of some of these techniques, so I'm going to go over that. So first we're going to start with kind of a background on ARP. For most of you, this is probably going to be pretty basic, but it's kind of essential to build what really ARP is and what it does and how we can attack it. So obviously network systems like in a network need a way to talk to each other. A lot of times we think of them talking to each other via protocol address like IP addresses, but on a local area network or physical network they actually have to talk via physical addresses and so we need a way to translate from our protocol address like our IP address to the physical addresses like MAC addresses. ARP in this particular talk, we're in reference in this talk, we're talking about ARP over Ethernet and in reference to IPv4. So ARP can work in other environments, but we're specifically talking about that particular environment right now. So the address resolution protocol allows us to resolve a hardware address from given a protocol address. So if we have an IP address like 192.168.1.100 and we want to talk to it, we can send an ARP request packet out to the broadcast of the network. It's kind of like a who has 192.168.1.100. And every host on the network since it's sent out to the broadcast gets this particular request packet and if their protocol address matches the protocol address in the field for the target protocol address in the ARP request packet, they send out a response to the sender saying I'm at blah, blah, blah. So here 192.168.1.100 sends out that they are at the hardware address 00DF1A9CA378. So, okay, so now we have a way of translating between protocol addresses or IP addresses and hardware addresses. But obviously there'd be a lot of chatter on a network, unnecessary chatter on a network. If for every packet or every frame that has to go out on a physical network, we have to send out an ARP request and receive an ARP reply. So hosts in order to overcome this overhead have local caches of MAC address and IP pairs. So it's the ARP cache. What this does is it just once we've resolved an IP and MAC pair, we cache it for a certain period of time locally so that when we go to communicate to another host again, we look in our table and if the ARP entry exists, then we know where to go. We don't have to send out an ARP request again. So this is where really part of the weaknesses in ARP kind of starts out is that particular table. So go over a little bit of a background and anatomy of an ARP packet to begin with. So this is kind of a typical ARP packet. One of the first field is hardware type field. And so this specifies what the underlying type of hardware that we're sending our frames on is. Typically, and in our environment that we're talking about today, this is going to be set to the code for Ethernet. Next we have the protocol type, which again specifies what protocol we're using. So this will be filled with the code for IPv4. Then the next two fields are hardware length and protocol length. Because we can use different protocols and different hardware mediums in order to send ARPs over, obviously the associated addresses can vary the length of those addresses. So we need a place to specify how long each field should be as far as the protocol length and the hardware length. So that's done in these two fields. We'll go over actual examples of ARP packets in a little bit. And what values go in there. The next is going to be the opcode. And this is typically going to be either a request or reply. So this is where in the packet we specify what kind of packet we're sending. If we're sending an ARP request or if we're sending an ARP reply. And that's how the associated hosts translate that packet when they receive it. The sender hardware address is pretty self-explanatory. This is the hardware address or MAC address in our case of the sender's Ethernet card or interface card. So whoever's sending out an ARP request or an ARP reply, they put their own hardware address of the interface it's going out into this field. Same thing with the sender protocol address. This is of course how in your typical or standard conversation, we're going to abuse these fields a little bit in order to get what we want out of it. So then you have the target hardware address, which is pretty self-explanatory again. It's the hardware address or MAC address of the target we're sending our packet to. And target protocol address, which would be the IP address of that target. So as an example, if 192.168.1.20 wants to speak with 192.168.1.100, they send 1.20 will send an ARP request packet out to the local network broadcast. And this is what the packet will look like. We see that the first field, the hardware type is set to 01, which is the code for Ethernet. The protocol type is set to IP. The Ethernet length is set to 6 because it's 6 bytes for an Ethernet address. And the protocol length is 4 because it's an IPv4 or 4 byte address. We also see the opcode is 1, which is the code for an ARP request. And then we have all the different, the sender hardware address, which is the requesters hardware address and their IP address in the protocol, the sender's protocol address. And then target hardware address, which here is set to null because that's what we're trying to do. We're trying to resolve what the hardware address for the IP address that we have. So that's set to null and sent out on the wire. And then we have the IP address that we're trying to resolve in the target protocol address. So the response looks like this. 182.168.1.100 replies, sends out an ARP reply with its hardware address, 00AABBCCDDFF. And it's specifically sent to 1.20 and to its, the target, you can see that the target hardware address and target protocol address are both filled out correctly. And the sender hardware address and sender protocol address are filled out with the host that's answering. This then, in turn, the host, 192.168.1.20 will take that and enter it into its ARP cache, or update its ARP cache for 1.100. So now it knows who belongs to 1.100 and doesn't have to send out more requests until a time out occurs. So traditional ARP attacks. One of the most common ARP attacks for taking over really any local area network is ARP cache poisoning. ARP cache poisoning is, since ARP is completely unauthenticated, you might have noticed as we were talking about, even if you're not familiar with ARP cache poisoning, the dangers as we were talking about, a host sends out an ARP request and it receives, somebody else sends out an ARP reply and when it receives that ARP reply, it updates its cache. It has no sort of authentication to verify who actually sent the ARP reply, so it doesn't really know who it's talking to. And that's what ARP cache poisoning is really about. You basically, since it's completely unauthenticated, whoever sends a reply to the requester first wins and gets their information, whether it's legitimate or spoofed, input into the ARP cache. We have another condition though where sometimes the ARP cache can be updated with gratuitous ARP replies. So even if the host didn't send out an ARP request and it's just humming along and receives an ARP reply, then it'll still update its cache because it's dumb. So basically that's really what most of the ARP cache poisoning tools rely on. Instead of waiting for an ARP request to go out and trying to race with the actual owner, it just sends out gratuitous ARP replies in order to try to update the cache. This isn't effective on all operating systems, but many operating systems, this is the case. So basically in order to exploit this, you just send out forged ARP reply packet to a victim. You put in the legitimate sender protocol address, whatever you want to hijack the connection of, and your MAC address or some other MAC address, and effectively poison the ARP cache so that the victim is now talking to you when it thinks it's talking to Joe Blow Gateway. So the results of this, as you can see, are probably the most common is man in the middle. If we poison an ARP cache entry with our own MAC address information, our own hardware information for say the gateway, then all the hosts or all the traffic between the host and the gateway or obviously any traffic going to host on the other side of the gateway are going to go through us first. So we can look at it, we can modify it, we can sniff it, whatever we want to do, classic man in the middle attack, and then pass it on to the gateway as if it were legitimate traffic, sorry. Another condition with this would be denial of service. So if we put in, instead of putting in our own MAC address or a legitimate MAC address in order to hijack the connection, we can just put in a bogus or non-existent random MAC address and now that host can't communicate with that the other host. So you can sever connections between hosts. Obviously the benefits of that can either be just simply profan or malicious or if it's used in conjunction with other attacks, like say we're attacking or attempting to exploit a vulnerable server but we know that we're already on the local network and we know that the server is logging to some central syslog server or reporting to some central intrusion detection sensor, then we can sever that connection, deny service between those two hosts and now prevent that external logging as we carry out the rest of our attack. So an example of man in the middle attack would be client sends an ARP request for 1.1 and we can see that it's a standard ARP request packet. So we have the sender hardware address and protocol address which are our victim host and then target hardware address again is null and we're looking up 192.168.1.1 and it's a request packet as you can see in the opcode field. Now before 1.1 responds the attacker now sends another ARP an ARP packet directly to 1.20 at 00AABBCCDDEE and says hey I'm 1.1 and it gives it its MAC address so 00AABBCC01AA. So now the attacker is actually the victim 1.20 is talking to the attacker where it thinks it's talking to the gateway 1.1 so the attacker can do anything it wants with that data stream inject things in, sniff on it, gather usernames and passwords anything that's relevant. Again an example of denial of service would be that 192.168.1.20 requests the hardware address of the gateway again same packet and the attacker instead of replying with his credentials in order to perform a man in the middle replies with bogus a bogus MAC address of 00AABBCCDDEE 01. So now the victim goes to try to talk to the gateway and can't the communications channel is severed because it doesn't really know the hardware address even though it thinks it knows the hardware address of 1.1 so it sends packets out and it never receives or 1.1 never receives them. Another ARP attack, classic ARP attack is a CAM table overflow and this has been around for a long time but the reason for this specific attack is that back in the day when anybody used hubs a hub is just a dumb piece of network equipment so two hosts communicating over a hub all of their traffic is forwarded to all of ports on that hub so if you were plugged in anywhere on that hub or that physical network you can intercept or sniff eavesdrop on any of that traffic and that conversation and even potentially inject things into stream as well and things like that so switches though are different as we probably all know that switches maintain a table this is actually called a CAM table or content addressable memory table and what this table holds is a matrix of pairs between port numbers and MAC addresses that are discovered on those port numbers along with some other information but what's relevant to our discussion right now is that MAC address and port number pair so the CAM table says that switch port 23 has these MAC addresses associated with it so when an Ethernet frame arrives at the switch instead of broadcasting that frame out to all ports it instead looks it up in the CAM table and only forwards it to the port where that MAC address actually exists so that kind of severs our ability to eavesdrop on conversations because now we're not getting that traffic even if we're in promiscuous mode or whatever that traffic just never received ends up on our network port so a CAM table overflow what it does is no matter how big your switch is no matter what kind of enterprise switch you have it's going to have a size limit to the CAM table I mean it's not going to be infinitely sized so there's going to be some point at which it can't it has to overflow or purge other information out of the table if it receives too much information so basically what you do to perform a CAM table overflow is you send hundreds or thousands of spoofed Ethernet frames with spoofed MAC addresses to the network and overflow the internal CAM table of the network switch so here the network switch gets filled up starts purging out legitimate data and now when legitimate traffic or legitimate frames enter the switch it doesn't have a pairing in that CAM table for a legitimate MAC address so it ends up broadcasting it to all of the ports on the switch so effectively turning the switch into a hub just like we're able to do before so now we can sniff again on we can now sniff again on traffic on the local network just like we were able to with the hub there are weaknesses though with these different ARP attacks ARP cache poisoning in particular most all of the current methods of ARP cache poisoning in the tools that perform this particular attack as well as different papers that identify how to do ARP cache poisoning utilize ARP reply packets as a way to inject the falsified information into a host ARP cache table but as we said before not all OSs most will update when it just receives a gratuitous ARP reply packet even though it didn't send out a request but not all OSs will some tools have overcome this by sniffing the network and so when it sees the first ARP request it races to respond faster than the legitimate host in order to inject its entry into the ARP cache a CAM table overflow obviously also has weaknesses and drawbacks CAM table overflow requires hundreds or sometimes many thousands of spoofed frames, spoofed MAC addresses in order to actually overflow depending on the switch that you're actually using so obviously if you're a savvy network engineer and you've got ethereal running then you can probably detect that an ARP cache or a CAM table overflow or something funky is happening on your network it's very identifiable, very noisy lots and lots of crap packets on your network and we also can prevent the traditional CAM table overflow with technologies like port security, Cisco's port security and other related types of technologies that actually can just limit the number of MAC addresses that are allowed to be identified on a given port so if we plug in to port 34 and we send out thousands of bogus frames then port security says oh well there's only ten allowed on this particular port and so then can either turn off the port or ignore traffic after that or whatever so we're not able to effectively overflow the CAM table because we can't get that many frames passed so this really kind of mitigates this is kind of the default answer for mitigating the risk of a CAM table overflow again really can't, the whole idea of a switch a switch is not a security device relying on that you have a switched network to prevent people from sniffing on your network is kind of retarded but people do and people that they rely on using port security or they had to add port security because this was kind of an issue along with other issues in switch networks so we're going to go over some new, kind of not completely new but attacks on ARP and kind of take a different approach than the traditional attacks to do this I wrote a tool called ARPcraft which basically just allows us to put together ARP packets and send them on the wire with whatever information we want put into the different fields of the ARP packet so this is kind of the different options that are available with ARPcraft we have, we can specify the interface we specify the source hardware address the source protocol address the target hardware address and protocol address whether what the opcode is whether it's a request or a plie packet and we can also specify the Ethernet source and Ethernet destination so if we want, by default the Ethernet source and destination match what the target hardware address and protocol address or sorry, target hardware address and source hardware address fields are but if we for some reason want to put a different MAC address in the Ethernet frame than we have in our ARP packet then we can do that with those flags again we can also set the interval so in seconds how often we want to send this packet out onto the wire by default I think it's at 5 seconds so every 5 seconds, whatever ARP packet we've built we send that out onto the wire every 5 seconds and then account, we can set how many we want to send out so if we just want to send out 1 or if we want to send out 5,000 we can set that without having to re-run the tool this is a pretty slide not quite sure what the point with that was anyway here's an example of using ARPcraft to send out an ARP request to the destination protocol address of 192.168.1.100 which has a hardware address of 00.00AABBCCDDFF and we want it to say that it's from 192.168.1.20 at the hardware address of 00AABBCCDDEE so we use ARPcraft and we specify the interface with the dash i dash sha we just put in our source hardware address in there, the MAC address that we want the packet to say it came from and the SPA, the source protocol address the IP address we want it to say it came from and then the target hardware address and target protocol address respectively and then the dash o flag we want to send out a request packet so here you'll see the tool kind of prints out a snapshot of what our packet looks like kind of a layout of what the different fields in the ARP packet are going to look like so that if something looks wrong you can cancel it and maybe you made a mistake in the options or whatever and then it just goes ahead and injects the ARP request to the wire same thing with this, just another example of let's see, hmm, anyway okay, so another approach to ARP cache poisoning, instead of basically instead of using ARP reply packets we went over the weaknesses already to a certain extent of ARP cache poisoning or the traditional methods of ARP cache poisoning so again, some OS's don't update their ARP cache just when they receive a gratuitous ARP reply most OS's, if not all OS's according to RFC, won't just add an ARP entry into the cache if it doesn't already exist in the cache when it receives a reply, so that's a little convoluted as far as that sentence, but basically what that means is if I'm a host and I receive a gratuitous ARP reply because I didn't send out an ARP request and then I just receive an ARP reply saying 182.168.1.1, the gateway is at, you know, blah if 1.1 is in my cache and I'm a retarded host then I will update my cache and say okay, 1.1 is at blah MAC address but I'm not going to add it to my cache if it doesn't already exist there I'll update it if it's already there but I'm not going to add a new host to my cache an ARP reply that I never sent out a request for then another weakness is like along the same lines, some OS's specifically Solaris, Solaris has kind of traditionally been kind of harder to perform ARP cache poisoning on because the problem is that Solaris doesn't rely, they don't really conform to the RFC specification as far as what to do when you receive an ARP request or reply if it has an entry in its table in its local cache and it receives either a reply or request or whatever it doesn't update it, if it differs from what it already has in its table it does nothing but instead it just goes on a timeout so it waits for that entry to timeout then it sends out a new ARP request and resolves it in that way so in order to poison you're basically stuck in this condition as far as you have to wait for Solaris to timeout its entry then send out the first request packet and respond with a reply faster than the legitimate host in order to poison a Solaris machine in a way that has, if you can do it correctly it has a certain benefit because then that host that entry, your forged entry is not going to be updated by even the legitimate server or legitimate machine, it's stuck in there until it times out we notice though that RFC 826 which specifies the ARP specification says that if instead of an ARP reply if a host receives an ARP request so if I am sitting along as JoBlo host and I receive a request for my information so my MAC address according to my IP then the target protocol address of course because it's sent out to broadcast if it matches the information that I have if it's my protocol address that it's looking for to resolve the MAC address then before responding first the host updates or adds the source protocol address and hardware address pair to the local cache so again if somebody asks me for my information whether if I have that information if I have their information in my cache or even if I don't first of all what I do is I check if it's in my cache if it is then I'll update it if it's not I actually add their information so basically it's for performance reasons so that if you don't have to both exchange and send out ARP requests only one request initiation will update the cache on both sides if you send out a request to a victim or to a host they'll update their cache with your information as well so that they have the cache now in order to speak with you further the actual verbiage from RFC 826 you can see there it's pretty straight forward it basically just says what I just said so instead of using an ARP reply packet we can use an ARP request packet to inject our information the information we want into an ARP cache I mean in order to poison their ARP cache so all we need is a single packet we don't have to wait for an ARP request to come out from them and try to race with a response all we need to do is send out a request with our information and most hosts will just update if that host already exists in the cache otherwise you can actually add new entries where with a reply packet it's not going to add a new entry into the cache but we can actually inject new entries into the cache using a request packet so here the attacker without being initiated by the victim 1.20 the attacker just sends a request packet to 1.20 saying it's from 1.1 but it's with the attacker's MAC address so we see that the opcode on this packet is 1 or a request so we're sending a request packet to 1.20 and saying the sender hardware address is 00AABBCC01AA which is the attacker's hardware address and then saying our protocol address is the gateways and then sending it to the victim their target hardware address and protocol address sorry? yes sorry? oh I'm sorry he said is it Unicast? yeah sorry I'm bad at that so throw things at me if I don't repeat the question so I'm going to kind of demo that so I'm going to send say here we have our victim here it's a free BSD box and I'm going to just enter a random MAC address and IP pair into its cache so here we have the current ARP cache which has an entry for 1.1 and 1.157 okay so we're just injecting 2.192.168.1.163 an ARP request packet from 1.2 saying that 1.2 is at 00AABBCC01AA so now we'll go over to the victim and look at the ARP cache and we have an entry for 1.2 at 00AABBCC01 so we can just arbitrarily enter entries into the ARP cache using request as opposed to just gratuitous reply packets I'll demo a little further that we can overwrite 1.1 our gateway with 00AABBCC01AA by using request packet 2 so here 1.1 now now we've overwritten the gateway address with 00AABBCC01AA so it's fairly straightforward ARP cache poisoning technique but it's just using a different packet type so it's a little bit more reliable on different hosts so again we talked about the weaknesses of some of the ARP poisoning techniques CAM table overflows they can be prevented with port security they can be very easily identified by an intrusion detection system or an administrator running TCP dump it takes thousands of packets usually in order to perform a successful CAM table overflow do you have a question static CAM entries static entries are usually a fairly acceptable defense for any of the even for ARP cache poisoning as well static ARP entries are probably the best way to go as far as defense in your average enterprise network you can't really create static entries for all of your hosts so that's obviously a mitigating problem so we went over those problems often usually we don't really need in a real targeted attack we don't really need to sniff the entire network for something I mean it might be nice sometimes but usually we're going after one machine or more targeted approach especially if stealth is in order at all so there's a couple of ways that we could already do that we can already inject into poison the ARP cache of a civic host so a man in the middle attack essentially allows us to sniff as well because traffic is going through us so it's kind of a targeted sniffing approach that's how most people get by sniffing on a switch network without using a CAM table overflow you just poison the ARP cache and perform a man in the middle attack and then you can sniff on that traffic but obviously that's not always appropriate because now your MAC address is the CAM or the ARP cache table of the victim so you can forensically and further it's just easier to identify who's actually perpetrating an attack but a little bit back before as far as the whole CAM table scenario if a switch receives a frame and checks its CAM and doesn't have that pair an entry that matches that frame it again it floods it to the entire network so we can accomplish the same thing as opposed to flooding and overflowing the entire CAM table we can accomplish this type of attack by just again utilizing the ARP cache poisoning technique instead of poisoning and performing a man in the middle attack we just poison the target with a null MAC address and so basically when the target sends it out onto the network the switch doesn't have an entry in its CAM table so it floods it to all ports again but it still gets through the gateway, the traffic is not going to be interrupted so even if you don't, if you're in a man in the middle attack you actually have to route the traffic back to the legitimate host here it gets to all the ports and the legitimate host is still going to pick it up because it's got a null destination on the frame so so we can kind of we can perform targeted sniffing or eavesdropping on a switched network by using this technique and this works on every switch that is out there because it's really the underlying principle is that it looks in the CAM table and since that pair, the null MAC address pair doesn't exist in the CAM table then it floods it to all the ports this doesn't require hundreds or thousands of packets it requires a single packet in order to inject or poison the ARP table of our victim host so port security is not going to stop it even if we're sending it to multiple hosts we're not sending spraying thousands of random MAC address or frames with random MAC addresses out to the network in order to overflow a CAM table it's only a single MAC address and so we're not using multiple entries in the allowable entries from port security etc and obviously it's less identifiable a single packet it's a lot less identifiable on your network than thousands of bogus packets few other fun little things with ARP some OSs can actually be poisoned with their own MAC address for the destination so here we can actually poison say we want to sever a connection or denial of service connection between a host and a logging server all we have to do is send a request packet again with the sender hardware address which equals the host that we're poisoning and the target hardware address equaling the host that we're poisoning and then the target protocol address and target sender protocol address with the hosts that were the target would be the host were poisoning and the sender would be the host that we're masquerading as and now we can completely it doesn't even send it out to the network because it thinks it's local and so the traffic never ends up on the switch so it can't communicate with the log server et cetera yeah windows will let you do it Solaris will let you do it I I don't think if I remember correctly FreeBSD I think doesn't do that it actually does check if it's already one of the local interfaces so just the tool Artcraft is going to be released so play around with it there's other network testing tools like Scapi and things like that that can do similar things so here obviously tries to log to a network syslog server the attacks that you've done after poisoning and cache so nobody's going to see anything other than on the local host so you pop whatever vulnerable service and drop the logs there another thing that's kind of cool or kind of fun silly is that if a host receives an ARP request or reply with the same protocol address as its own or one of its own interfaces but a different MAC address so some other host on the network is saying that it has that IP address then most OS's Windows Nix's things like that will complain to the user whether it's via syslog or console log or in case of Windows it actually pops up a dialogue there's duplicate IP address on the network so you can play games with Windows users by sending them or popping up this nice dialogue or a bunch of times there's no real engineering attempts actually because if you do this a bunch of times in a row or just do it in a loop it actually burns up quite a bit of clock cycles I've had Windows machines just crash if you just kind of keep sending them but or if you just do it for a little amount of time and you call up as tech support and say that apparently they've been having conflict of IP addresses and ask for their username and password most people actually do it it's kind of fun other fun with ARP the Kaminsky factor got to throw in a covert channel over any protocol like DNS or ARP or whatever so just like any protocol that has optional fields or fields that you can play with you can throw other data in it and get it across so we can use ARP secret information over a local area network basically I had a demo but it's the other hardware not working so but I do have a better demo actually so we're actually in this case just using a sender hardware address field which is just four bytes or six bytes of bandwidth per packet like I said four I had to rewrite this stupid slide deck last night because I only brought the PDF version stupidly so excuse any typos please because I wasn't not partying either so anyway we get six bytes of bandwidth per packet somebody's saying something and then basically in order to just kind of simply obfuscate the message over the wire we just threw in a little bit of XOR encryption with a shared key between the client and server and can receive secret messages we could increase the bandwidth per packet by using more than one field or even more simply since like we went over we can specify the length of the address fields we can specify whatever length we want for the hardware address field or the protocol address field and just stuff as much data as we want a length of 1,024 and stuff a kilobyte of data into that hardware address field or the protocol address field and put one packet on the network and get all the data we want another kind of kind of extra thing instead of just passing messages over the network I kind of went a step further through together ARP SH I'm going to show you just a fun little proof of concept remote so called encrypted shell over ARP so fun for back doors kind of just proof of concept it's totally buggy right now but basically it consists of two parts ARP SHD and ARP SH and again we just obfuscate the data so dumb network administrators can't just see our complete traffic via XOR encryption and a simple shared key so I'll demo that here's our victim so somehow we've popped this machine with whatever vulnerability or whatever so we're going to start ARP SHD and over here actually over here we'll just start a network sniffer so we can see what traffic is actually being passed it's not actually wrapping it through town that or some crap like that so put that up here and we so there's no ports listening on the victim server or anything like that it's just monitoring ARP traffic and detecting our command executing it and sending it back all over ARP you can see all the traffic here so fun stuff the moral as far as that goes is just you can't really trust any protocol to be what it really says it is what we're doing there is again just sending the data via the sender hardware address sending a little bit what two minutes oh sorry well I think we're so ARP Venom is a tool that it kind of automates these attacks check did drive.org for release and updates on that it should be up pretty soon I don't think it's I got it posted yet so again traditional ARP attacks work well and they're good standbys they have certain weaknesses so there's certain cases where you can use some of the techniques that I showed today that would be a little bit more effective targeted sniffing can be again accomplished by poisoning with Null MAC addresses for the intended destination a lot less noisy than cam table overflow can still do kind of the same thing so a lot more reliable too for switches that have port security and things built in so any questions I'm sorry yeah the question was if you poison a victim with a Null MAC address in order to do sniffing does the destination host while you get the data and are able to sniff the data is the transmission interrupted? does the destination actually still get and process the data and yes in most every case it does actually accept and process that packet anyone else? well thank you thanks for your time