An easy method is for the provider to configure their DNS server so that it periodically does a kind of traceroute in its reply. Then, count the hops back to the requesting machine. Are there any hops beyond the client ip interface? Then they're using NAT.
The standard RedHat dhcp client, "pump" that is part of the RedHat 6.2 distribution never worked with the @home dhcp server in my area (colorado). The replacement dhcp-2.0-5 worked fine with @home, and works fine with attbi.
I made the following change to/etc/sysconfig/network-scripts/ifup:
# if/sbin/pump $PUMPARGS -i $DEVICE ; then
if/sbin/dhcpcd $PUMPARGS -i $DEVICE ; then
UWB systems produce RF emissions across a vast bandwidth, exceeding 1 GHz in some cases. Many devices don't have a conventional carrier frequency, but are characterized by a "maximum in the power spectrum envelope." Within any given conventional frequency band, the receivable power from a single UWB device is so low that it is far below the noise threshold of the conventional devices that operate in that band. The emissions are not receivable even by sensitive measurement equipment unless the UWB device is within few meters. For these types of wideband emissions, the potential for interference is determined entirely by the nuances of the "victim" receiver implementation. Conventional spectrum management techniques rely on the existence of an interference threshold -- a power level which may be measured independently of a particular receiver implementation. This threshold does not exist in the same sense for UWB devices; a separate value and measurement technique would have to be defined for every receiver implementation in the entire emission rage of the UWB device itself. The UWB industry claims (and has some evidence to support) that such an exhaustive list of values is not necessary given the low power level of the devices.
The important questions is how potential victim receivers will cope with an aggregate of many UWB emitters operating at the same time. If this technology is widely adopted, will there be an aggregate noise effect that is significant? Much work has already been done to cope with the noise properties of microwave ovens, which are centered at 2.45 GHz. See this report , p. 48 of the pdf. The large hump near 2.45 GHz is due to emissions from microwave ovens, and is measurable anywhere there is a sizable population (town > 20,000 people) in the U.S. Microwave ovens are very different than UWB devices -- they emit several orders of magnitude more power, and are bandwidth limited, but there are many technologies that operate within this band despite their emissions (802.11b is one of them). These technologies were designed specifically to operate in the noise environment generated by microwave ovens, and the band itself is designated to be a kind of "free for all" frequency range known as an ISM (Industrial, Scientific and Medical) band. Existing receivers in the bands where UWB devices produce emissions were not designed in such a manner.
Nevertheless, the potential increase in communication capacity offered by UWB devices demands that it be scrutinized for interoperability with these existing receivers, and given a chance to fulfill its promise.
This looks to be a clever exploit on the way CD readers work.
References:
http://www.ttrtech.com/tech.htm
http://www.ee.washington.edu/conselec/CE/kuhn/cdau dio2/95x7.htm
Apparently, CD readers are capable of reading the data from audio cd's in two different modes: a generic-data-style read and an audio-data-style read. The audio-data-style read is meant to be directly converted to analog music via D/A converters in the unit. The difference is that the generic-data-style read imposes some data-integrity checks which, if fail, cause the reader to report a read error or return erroneous data. The audio-data-style read can ignore these errors to avoid interrupting the music.
This exploit appears to intentionally insert bits into the EFM stream so that a general-data-style read will fail or produce erroneous data. Since all CD copying techniques must use this type of access, they will fail as well. Normal consumer CD audio players will correct or ignore the errors with no impact on the music. High-end audiophile CD players that allow for custom DSP and D/A algorithms and use a generic-data-style read could suffer as well.
If a CD reader unit could be hacked to capture the data immediately after the error correction and before the D/A converter, then this technique could in theory be defeated.
Slashdot Mirror
An easy method is for the provider to configure their DNS server so that it periodically does a kind of traceroute in its reply. Then, count the hops back to the requesting machine. Are there any hops beyond the client ip interface? Then they're using NAT.
The standard RedHat dhcp client, "pump" that is part of the RedHat 6.2 distribution never worked with the @home dhcp server in my area (colorado). The replacement dhcp-2.0-5 worked fine with @home, and works fine with attbi.
/etc/sysconfig/network-scripts/ifup:
/sbin/pump $PUMPARGS -i $DEVICE ; then
/sbin/dhcpcd $PUMPARGS -i $DEVICE ; then
I made the following change to
# if
if
UWB systems produce RF emissions across a vast bandwidth, exceeding 1 GHz in some cases. Many devices don't have a conventional carrier frequency, but are characterized by a "maximum in the power spectrum envelope." Within any given conventional frequency band, the receivable power from a single UWB device is so low that it is far below the noise threshold of the conventional devices that operate in that band. The emissions are not receivable even by sensitive measurement equipment unless the UWB device is within few meters. For these types of wideband emissions, the potential for interference is determined entirely by the nuances of the "victim" receiver implementation. Conventional spectrum management techniques rely on the existence of an interference threshold -- a power level which may be measured independently of a particular receiver implementation. This threshold does not exist in the same sense for UWB devices; a separate value and measurement technique would have to be defined for every receiver implementation in the entire emission rage of the UWB device itself. The UWB industry claims (and has some evidence to support) that such an exhaustive list of values is not necessary given the low power level of the devices.
The important questions is how potential victim receivers will cope with an aggregate of many UWB emitters operating at the same time. If this technology is widely adopted, will there be an aggregate noise effect that is significant? Much work has already been done to cope with the noise properties of microwave ovens, which are centered at 2.45 GHz. See this report , p. 48 of the pdf. The large hump near 2.45 GHz is due to emissions from microwave ovens, and is measurable anywhere there is a sizable population (town > 20,000 people) in the U.S. Microwave ovens are very different than UWB devices -- they emit several orders of magnitude more power, and are bandwidth limited, but there are many technologies that operate within this band despite their emissions (802.11b is one of them). These technologies were designed specifically to operate in the noise environment generated by microwave ovens, and the band itself is designated to be a kind of "free for all" frequency range known as an ISM (Industrial, Scientific and Medical) band. Existing receivers in the bands where UWB devices produce emissions were not designed in such a manner.
Nevertheless, the potential increase in communication capacity offered by UWB devices demands that it be scrutinized for interoperability with these existing receivers, and given a chance to fulfill its promise.
This looks to be a clever exploit on the way CD readers work. References: http://www.ttrtech.com/tech.htm http://www.ee.washington.edu/conselec/CE/kuhn/cdau dio2/95x7.htm
Apparently, CD readers are capable of reading the data from audio cd's in two different modes: a generic-data-style read and an audio-data-style read. The audio-data-style read is meant to be directly converted to analog music via D/A converters in the unit. The difference is that the generic-data-style read imposes some data-integrity checks which, if fail, cause the reader to report a read error or return erroneous data. The audio-data-style read can ignore these errors to avoid interrupting the music.
This exploit appears to intentionally insert bits into the EFM stream so that a general-data-style read will fail or produce erroneous data. Since all CD copying techniques must use this type of access, they will fail as well. Normal consumer CD audio players will correct or ignore the errors with no impact on the music. High-end audiophile CD players that allow for custom DSP and D/A algorithms and use a generic-data-style read could suffer as well.
If a CD reader unit could be hacked to capture the data immediately after the error correction and before the D/A converter, then this technique could in theory be defeated.