That was about 1994. To the best of my knowledge, the protocol was
never implimented in hardware, but parts and pieces were borrowed for
various subsequent protocols. Note that although Wi-Fi was "invented"
around 1991, during the time the paper was written, most wireless
protocols were proprietary. The articles does hint that they plan to
test it on an NCR Wavelan card, which was literally the original
900MHz DSSS 802.11 card.
<http://www.qsl.net/n9zia/wireless/wavelan-cardmap.html>
On 20 Feb 2009 02:38:42 +0100, JSmith <JSmith@nospam.org> wrote:
>Dlink is running some form of this on my public wifi connection.
>Running a sniffer on it, I see lots of UDP packets coming to me with
>one of the content words being "Cache". Not sure what the purpose of
>these packets are? Anyone know?
No clue. Are you sniffing packets going over the air or over the
ethernet? If OTA, it's something else. The Snoop Protocol was
suppose to cache packets in the access point. It makes no sense to
transmit the contents of the cache as the whole idea is to NOT
transmit or retransmit its contents.
Try sniffing with Wireshark and see if it can decode the type header
into identifying the traffic. My guess(tm) is some kind of streaming
media or file sharing using UDP Host Cache.
>Jeff Liebermann <jeffl@cruzio.com> wrote in
>news:j8grp41hearf96j7aecjheo4fumfog4d4n@4ax.com :
>
>> On 18 Feb 2009 20:39:22 -0500, ohmy <ohmy@ohmyohmy.org> wrote:
>>
>>>Anyone on this group familiar with snoop protocol and it's caching
>>>algorithims for wifi?
>>
>> <http://bwrc.eecs.berkeley.edu/public...t_wireless_tcp
>> .hotos5/hotos.pdf>
>>
>> That was about 1994. To the best of my knowledge, the protocol was
>> never implimented in hardware, but parts and pieces were borrowed for
>> various subsequent protocols. Note that although Wi-Fi was "invented"
>> around 1991, during the time the paper was written, most wireless
>> protocols were proprietary. The articles does hint that they plan to
>> test it on an NCR Wavelan card, which was literally the original
>> 900MHz DSSS 802.11 card.
>> <http://www.qsl.net/n9zia/wireless/wavelan-cardmap.html>
>>
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.comjeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
On 20/02/2009 09:33, LR wrote:
> On 20/02/2009 05:08, Jeff Liebermann wrote:
>> On 20 Feb 2009 02:38:42 +0100, JSmith<JSmith@nospam.org> wrote:
>>
>>> Dlink is running some form of this on my public wifi connection.
>>> Running a sniffer on it, I see lots of UDP packets coming to me with
>>> one of the content words being "Cache". Not sure what the purpose of
>>> these packets are? Anyone know?
>>
>> No clue. Are you sniffing packets going over the air or over the
>> ethernet? If OTA, it's something else. The Snoop Protocol was
>> suppose to cache packets in the access point. It makes no sense to
>> transmit the contents of the cache as the whole idea is to NOT
>> transmit or retransmit its contents.
> ??
> "The job of the Snoop Agent is to cache data packets for a TCP
> connection. When the data packets are determined to be lost, identified
> by duplicate Acks, it retransmits the data packets. The Snoop Agent
> re-transmits the packets locally without forwarding the Acks to the
> sender. As a result, the TCP layer is not aware of the packet loss and
> congestion control algorithm is not triggered.
> In addition, the Snoop Agent starts a retransmission timer for each TCP
> connection. When the retransmission timer expires, the Snoop Agent will
> retransmit the packets that have not yet acknowledged."
> <http://www.ensc.sfu.ca/~ljilja/ENSC833/Spring01/Projects/chow_ng/snoop_report.pdf>
>
> The pdf contains the "Snoop Protocol Module Source Code"
>
> Some people are still interested in "Snoop" going by the fact that
> SourceForge.net has a linux version dated 4th Feb 2008
> <http://sourceforge.net/projects/bsnoop/>
>
>
>
>
>
Some comparative tests were run on 802.11b against FEC and in
conjunction with FEC.
<http://www.china-cic.org.cn/english/digital%20library/200510/5.pdf>
Jeff Liebermann <jeffl@cruzio.com> wrote in
news:jcesp411uq367b2qm6g2ajqcmvs3rqtmn2@4ax.com:
> On 20 Feb 2009 02:38:42 +0100, JSmith <JSmith@nospam.org> wrote:
>
>>Dlink is running some form of this on my public wifi connection.
>>Running a sniffer on it, I see lots of UDP packets coming to me with
>>one of the content words being "Cache". Not sure what the purpose of
>>these packets are? Anyone know?
>
> No clue. Are you sniffing packets going over the air or over the
> ethernet? If OTA, it's something else. The Snoop Protocol was
> suppose to cache packets in the access point. It makes no sense to
> transmit the contents of the cache as the whole idea is to NOT
> transmit or retransmit its contents.
Sorry for late reply, not at my usual location.
OTA. These packets only come with the dlink AP, not with other ones.
Also multiple ICMP incoming packets that do not occur at 1 sec intervals
like the UDP ones and when I disabled "Destination Unreachable" I was
unable to get replies to http post packets to web pages.
>
> Try sniffing with Wireshark and see if it can decode the type header
> into identifying the traffic. My guess(tm) is some kind of streaming
> media or file sharing using UDP Host Cache.
Could be P2P, not sure. I am going to try to get commview for wifi.
Not familiar with Wireshark, is it better? These UDP packets act like
some kind of beacon judging from their 1 sec intervals and they are all
on the same incoming port. When blocked the do not seem to effect my net
activities, but I don't like my little computer having to deal with
them.
>
>>Jeff Liebermann <jeffl@cruzio.com> wrote in
>>news:j8grp41hearf96j7aecjheo4fumfog4d4n@4ax.co m:
>>
>>> On 18 Feb 2009 20:39:22 -0500, ohmy <ohmy@ohmyohmy.org> wrote:
>>>
>>>>Anyone on this group familiar with snoop protocol and it's caching
>>>>algorithims for wifi?
>>>
>>>
<http://bwrc.eecs.berkeley.edu/public...ent_wireless_t
>>> cp .hotos5/hotos.pdf>
>>>
>>> That was about 1994. To the best of my knowledge, the protocol was
>>> never implimented in hardware, but parts and pieces were borrowed
>>> for various subsequent protocols. Note that although Wi-Fi was
>>> "invented" around 1991, during the time the paper was written, most
>>> wireless protocols were proprietary. The articles does hint that
>>> they plan to test it on an NCR Wavelan card, which was literally the
>>> original 900MHz DSSS 802.11 card.
>>> <http://www.qsl.net/n9zia/wireless/wavelan-cardmap.html>
>>>
LR <lrme@privacy.net> wrote in
news:EM6dney1Wotv5QPUnZ2dneKdnZydnZ2d@bt.com:
> On 20/02/2009 05:08, Jeff Liebermann wrote:
>> On 20 Feb 2009 02:38:42 +0100, JSmith<JSmith@nospam.org> wrote:
>>
>>> Dlink is running some form of this on my public wifi connection.
>>> Running a sniffer on it, I see lots of UDP packets coming to me with
>>> one of the content words being "Cache". Not sure what the purpose of
>>> these packets are? Anyone know?
>>
>> No clue. Are you sniffing packets going over the air or over the
>> ethernet? If OTA, it's something else. The Snoop Protocol was
>> suppose to cache packets in the access point. It makes no sense to
>> transmit the contents of the cache as the whole idea is to NOT
>> transmit or retransmit its contents.
> ??
> "The job of the Snoop Agent is to cache data packets for a TCP
> connection. When the data packets are determined to be lost,
> identified by duplicate Acks, it retransmits the data packets. The
> Snoop Agent re-transmits the packets locally without forwarding the
> Acks to the sender. As a result, the TCP layer is not aware of the
> packet loss and congestion control algorithm is not triggered.
> In addition, the Snoop Agent starts a retransmission timer for each
> TCP connection. When the retransmission timer expires, the Snoop Agent
> will retransmit the packets that have not yet acknowledged."
> <http://www.ensc.sfu.ca/~ljilja/ENSC8.../chow_ng/snoop
> _report.pdf> The pdf contains the "Snoop Protocol Module Source Code"
Ok, from what your saying udp packets incoming to the same port at 1-sec
intervals do not sound like they are part of snoop protocol, must be
something else.
>
> Some people are still interested in "Snoop" going by the fact that
> SourceForge.net has a linux version dated 4th Feb 2008
> <http://sourceforge.net/projects/bsnoop/>
>
>
>
>
>
On 24/02/2009 00:48, JSmith wrote:
> Jeff Liebermann<jeffl@cruzio.com> wrote in
> news:jcesp411uq367b2qm6g2ajqcmvs3rqtmn2@4ax.com:
>
>> On 20 Feb 2009 02:38:42 +0100, JSmith<JSmith@nospam.org> wrote:
>>
>>> Dlink is running some form of this on my public wifi connection.
>>> Running a sniffer on it, I see lots of UDP packets coming to me with
>>> one of the content words being "Cache". Not sure what the purpose of
>>> these packets are? Anyone know?
>> No clue. Are you sniffing packets going over the air or over the
>> ethernet? If OTA, it's something else. The Snoop Protocol was
>> suppose to cache packets in the access point. It makes no sense to
>> transmit the contents of the cache as the whole idea is to NOT
>> transmit or retransmit its contents.
>
> Sorry for late reply, not at my usual location.
> OTA. These packets only come with the dlink AP, not with other ones.
> Also multiple ICMP incoming packets that do not occur at 1 sec intervals
> like the UDP ones and when I disabled "Destination Unreachable" I was
> unable to get replies to http post packets to web pages.
>
>> Try sniffing with Wireshark and see if it can decode the type header
>> into identifying the traffic. My guess(tm) is some kind of streaming
>> media or file sharing using UDP Host Cache.
>
> Could be P2P, not sure. I am going to try to get commview for wifi.
> Not familiar with Wireshark, is it better? These UDP packets act like
> some kind of beacon judging from their 1 sec intervals and they are all
> on the same incoming port. When blocked the do not seem to effect my net
> activities, but I don't like my little computer having to deal with
> them.
Some DLink routers and AP's have a setting for endpoint filtering and it
is possible that the one you are connected to is set for "Endpoint
Independent" for UDP.
"Endpoint Independent
Once a LAN-side application has created a connection through a
specific port, the NAT will forward any incoming connection requests
with the same port to the LAN-side application regardless of their
origin. This is the least restrictive option, giving the best
connectivity and allowing some applications (P2P applications in
particular) to behave almost as if they are directly connected to the
Internet."
Note the "regardless of their origin"
You could try using Wireshark as Jeff suggested and see what you get for
endpoint information.
<http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html>
OK thanks for the followup, I will try to learn more.
>LR <lrme@privacy.net> wrote in >
news:N66dnSJ8Wu7SID7UnZ2dnUVZ8tqWnZ2d@bt.com:
<snip>
>
> Some DLink routers and AP's have a setting for endpoint filtering and it
> is possible that the one you are connected to is set for "Endpoint
> Independent" for UDP.
> "Endpoint Independent
> Once a LAN-side application has created a connection through a
> specific port, the NAT will forward any incoming connection requests
> with the same port to the LAN-side application regardless of their
> origin. This is the least restrictive option, giving the best
> connectivity and allowing some applications (P2P applications in
> particular) to behave almost as if they are directly connected to the
> Internet."
>
> Note the "regardless of their origin"
>
> You could try using Wireshark as Jeff suggested and see what you get for
> endpoint information.
> <http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html>
>
>
On 24 Feb 2009 20:36:15 +0100, JSmith <JSmith@nospam.org> wrote:
>OK thanks for the followup, I will try to learn more.
You never answered my question as to whether you were sniffing the
wireless traffic or the ethernet. If this is your first experience
with Wireshark, I suggest you start by sniffing the ethernet (through
an ethernet hub setup as an ethernet tap). Wireless sniffing is a bit
messy. It's also done using Linux as Windoze requires an expensive
3rd party promiscuous/monitor mode driver.
There are also tutorials on how to sniff wireless with Wireshark.
Google finds quite a few:
<http://www.google.com/search?hl=en&q=how+to+sniff+wireless+wireshark>
There are also some tutorials on YouTube for Wireshark:
<http://www.youtube.com/results?search_type=&search_query=wireshark>
Jeff Liebermann <jeffl@cruzio.com> wrote in
news:a3l8q45qnqet93i5hs7u53af46am1os8av@4ax.com:
> On 24 Feb 2009 20:36:15 +0100, JSmith <JSmith@nospam.org> wrote:
>
>>OK thanks for the followup, I will try to learn more.
>
> You never answered my question as to whether you were sniffing the
> wireless traffic or the ethernet. If this is your first experience
> with Wireshark, I suggest you start by sniffing the ethernet (through
> an ethernet hub setup as an ethernet tap). Wireless sniffing is a bit
> messy. It's also done using Linux as Windoze requires an expensive
> 3rd party promiscuous/monitor mode driver.
Yes I did, did it not thread properly or you did not get it? See below.
I am using an older version of commview now on a win98se box and it does
show packets from other computers, so I am thinking it is already doing
promiscuous? Since this is an unencrypted connection to an AP, I have
seend some of the contents of these packets, but some also look
encrypted. There is a commview made specifically for wireless, are you
familiar with that? I d/l and older version of Wireshark and I will see
what it does.
Jeff Liebermann <jeffl@cruzio.com> wrote in
news:jcesp411uq367b2qm6g2ajqcmvs3rqtmn2@4ax.com:
>
> There are also tutorials on how to sniff wireless with Wireshark.
> Google finds quite a few:
> <http://www.google.com/search?hl=en&q=how+to+sniff+wireless+wireshark>
> There are also some tutorials on YouTube for Wireshark:
> <http://www.youtube.com/results?search_type=&search_query=wireshark>
>
>
Ok thanks for the link. Not sure why you did not get my reply that it
was OTA I was sniffing. I am on a rather primitive connection here so
hard to navigate. I answered my packet question via another route, the
packets are UnPnP UDP packets, not snoop as I was thinking. They are
supposedly a threat to WinXP, which I am not running, so I just blocked
them with my firewall. But I still don't like the fact that my weak
computer has to discard them all. I still don't know what the periodic
ICMP packets are, I will try to sniff them out.
====
>> On 20 Feb 2009 02:38:42 +0100, JSmith <JSmith@nospam.org> wrote:
>>
>>>Dlink is running some form of this on my public wifi connection.
>>>Running a sniffer on it, I see lots of UDP packets coming to me with
>>>one of the content words being "Cache". Not sure what the purpose of
>>>these packets are? Anyone know?
>>
>> No clue. Are you sniffing packets going over the air or over the
>> ethernet? If OTA, it's something else. The Snoop Protocol was
>> suppose to cache packets in the access point. It makes no sense to
>> transmit the contents of the cache as the whole idea is to NOT
>> transmit or retransmit its contents.
>
>Sorry for late reply, not at my usual location.
>OTA. These packets only come with the dlink AP, not with other ones.
>Also multiple ICMP incoming packets that do not occur at 1 sec
>intervals like the UDP ones and when I disabled "Destination
>Unreachable" I was unable to get replies to http post packets to web
>pages.
>
On 26 Feb 2009 08:12:38 +0100, JSmith <JSmith@nospam> wrote:
>Yes I did, did it not thread properly or you did not get it?
I found the message where you replied that you were sniffing OTA.
Sorry, I must have missed it.
>There is a commview made specifically for wireless, are you
>familiar with that?
Yes. I didn't want to spend $150 to try it.
<http://www.tamos.com/products/commview/>
>I d/l and older version of Wireshark and I will see
>what it does.
Why an older version of Wireshark? Note that it won't work in
promiscuous mode without the CACE AirPcap driver and dongle.
<http://www.cacetech.com/products/airpcap_family.htm>
In another posting, you were wondering if promiscous mode was working
with Commview. If you can see packets that ORIGINATE from remote MAC
addresses, it's working. Packets with destination MAC addresses (or
IP addresses) don't count.
>I answered my packet question via another route, the
>packets are UnPnP UDP packets, not snoop as I was thinking.
Ok, that makes sense. So, why would UPnP packets have a content of
"cache"? I'll plead ignorance.
>They are
>supposedly a threat to WinXP, which I am not running, so I just blocked
>them with my firewall. But I still don't like the fact that my weak
>computer has to discard them all. I still don't know what the periodic
>ICMP packets are, I will try to sniff them out.
They are a problem, but one small packet per second isn't going to
make much difference when your wireless can move thousands of packets
per second. Yeah, it contributes to overhead, but not that much. I
turn off UPnP for no better reason that it doesn't do anything useful
for my customers.
Jeff Liebermann <jeffl@cruzio.com> wrote in
news:971eq49qonndvgn6hdr8kklkccl6na39i9@4ax.com:
> On 26 Feb 2009 08:12:38 +0100, JSmith <JSmith@nospam> wrote:
>
<snip>
>
> Yes. I didn't want to spend $150 to try it.
> <http://www.tamos.com/products/commview/>
I am using an older version which I really like, so I might try the
one for wireless if wiershark doesn't do it.
>
>>I d/l and older version of Wireshark and I will see
>>what it does.
>
> Why an older version of Wireshark? Note that it won't work in
> promiscuous mode without the CACE AirPcap driver and dongle.
> <http://www.cacetech.com/products/airpcap_family.htm>
Only ver up to .99.0 works with 98se; that's before the name change from
etheral. also the company was really nice in email exchanges. I don't
like the software where they make you run around getting more software
so their software will work. But that was when I was running w95 and I
think it was wcap you had to install and that came with user unfriendly
instructions. Thanks for the link to aircap, might try it.
>
> In another posting, you were wondering if promiscous mode was working
> with Commview. If you can see packets that ORIGINATE from remote MAC
> addresses, it's working. Packets with destination MAC addresses (or
> IP addresses) don't count.
ok not at my usual place now, so will take another look at the sniffer
output.
>
>>I answered my packet question via another route, the
>>packets are UnPnP UDP packets, not snoop as I was thinking.
>
> Ok, that makes sense. So, why would UPnP packets have a content of
> "cache"? I'll plead ignorance.
will take a second look, don't know offhand; don't have the logs handy.
>
>>They are
>>supposedly a threat to WinXP, which I am not running, so I just
>>blocked them with my firewall. But I still don't like the fact that my
>>weak computer has to discard them all. I still don't know what the
>>periodic ICMP packets are, I will try to sniff them out.
>
> They are a problem, but one small packet per second isn't going to
> make much difference when your wireless can move thousands of packets
> per second. Yeah, it contributes to overhead, but not that much. I
> turn off UPnP for no better reason that it doesn't do anything useful
> for my customers.
On Mon, 2 Mar 2009 23:12:13 +0000 (UTC), ElliottW <ElliottW@msn.com>
wrote:
>Jeff Liebermann <jeffl@cruzio.com> wrote in
>news:971eq49qonndvgn6hdr8kklkccl6na39i9@4ax.com :
>> Why an older version of Wireshark? Note that it won't work in
>> promiscuous mode without the CACE AirPcap driver and dongle.
>> <http://www.cacetech.com/products/airpcap_family.htm>
>Are you saying that AirPCap will not work without their hardware under
>any circumstances?
Yes, it will only work with their USB adapter.
>The AirPcap driver cannot be used with other
>adapters??
No, it will not work with other adapters.
Well, I've never bought or used AirPcap, but I guess I can decode the
web pages:
<http://www.cacetech.com/products/airpcap_family.htm>
Note that the cheapest offering includes a USB adapter:
<http://www.cacetech.com/products/catalog/product_info.php?products_id=40&osCsid=bb1ce2e1b19 bc8af8b4b64841724f707>
The license also clearly indicates that you are buying the software
license and the USB adapter:
<http://www.cacetech.com/products/catalog/license_airpcap.htm>
Ah... here's the fine print:
Scope of License. CACE grants to you a perpetual, fully-paid,
non-exclusive, non-transferable, nonsublicensable, revocable
license to use the AirPcap Software that you obtain under this
Agreement, solely and exclusively for use with the AirPcap
Wireless Adapter that was purchased with the AirPcap Software
from CACE Technologies, Inc.
Exclusively for use with the AirPcap Wireless Adapter means that it
will only work with the supplies USB adapter. There's no mention of
compatible adapters on any page I could find.
>If it will not, are there any alternative apps for
>grabbing pass packets on even a single channel?
Sure. Anything that's Linux based. It's not as horrible as it
sounds. Grab a LiveCD such as:
<http://www.remote-exploit.org/backtrack.html>
<http://wiki.remote-exploit.org>
It includes the Linux version of Wireshark. See the bottom two screen
shots at:
<http://www.remote-exploit.org/backtrack_screenshots.html>
Sone tutorials and YouTube videos on installing and using Backtrack 3.
Find with Google.
There are also some hacked and obscure promiscuous mode drivers that
work under Windoze. I don't wanna go there.
On Tue, 3 Mar 2009 01:16:31 +0000 (UTC), ElliottW <ElliottW@msn.com>
wrote:
>hahahaha ;-) go directly to BSD, do not pass go.
FreeBSD and the various Linux mutations are fairly similar. Well, at
the command line level, they're about 90% the same. However, the 10%
that is different will drive you nuts. I would recommend Ubuntu
Workstation for beginners.
>I know a little nix, but I think it may be a hassle finding free apps
>for it and getting all the drivers to work.
Pick your hardware carefully and just make sure that Linux drivers are
available. Atheros chipsets seem to be the best supported for
wireless:
<http://lwn.net/Articles/278132/>
>Thanks for the links I might
>try Linux. I am running a hardware handicapped machine; last time I
>tried to use some AV linux based "live" cds, from 3 diff. mfgs, none of
>them would load or work.
What's your time worth? What's the machine worth? You do the math.
Besides, if it were easy, it would be no fun.
Compatibility list for Backtrack:
<http://wiki.remote-exploit.org/index.php/Hardware_Compatibility>
Linux on laptops:
<http://www.linux-laptop.net>
>Yeah found out about that today, but problems getting them to work in
>promiscuous mode. I think I have the prism chipset on my senao knockoff.
There are at least 3 different chip manufacturers and perhaps 8
different chips that are delivered inside "Prism" wireless devices:
<http://www.seattlewireless.net/index.cgi/SenaoCard>
Hint: Numbers are a good thing.
Re: Snoop Protocol; Caching 
Linear Mode
