Archive

Archive for April, 2009

Compiling Splat! on Ubuntu 8.10 x86_64

April 29th, 2009 jesse No comments

SPLAT! is an RF Signal Propagation, Loss, And Terrain analysis tool for the spectrum between 20 MHz and 20 GHz.

Unfortunately, compiling this out of the box threw a number of compiler errors. Here’s what I found & how I fixed it.

8854

Target system:

  • Ubuntu 8.10 x86_64 (64 bit)

Supporting libraries installed for this program:

  • libbz2-dev
  • libzzip-dev
  • llib1g-dev

splat.cpp

Problem:
Compiler complains of a potential buffer overrun

Details:
Offending lines are here:
line 1663 strncat(path_plus_name,sdf_file,255);
line 1896 strncat(path_plus_name,sdf_file,255);

The offending variables are declared here:
line 1612 char path_plus_name[255]
line 1842 char path_plus_name[255]

Solution:
Double the path_plus_name char size to 512 bytes

Explanation:
On lines 1663 and 1896 strncat creates a potential buffer overrun condition by concatenating sdf_file[255] with path_plus_name[255]. There is some earlier logic that ensures this won’t happen, but the compiler throws a fit regardless. This is corrected by doubling the path_plus_name size to 512 byte.
Line 1612 modified char path_plus_name[512]
Line 1852 modified char path_plus_name[512]

Background:
char * strncat ( char * destination, char * source, size_t num );
Appends the first num characters of source to destination, plus a terminating null-character. If the length of the C string in source is less than num, only the content up to the terminating null-character is copied.

destination
Pointer to the destination array, which should contain a C string, and be large enough to contain the concatenated resulting string, including the additional null-character.

source
C string to be appended.

num
Maximum number of characters to be appended.

Build Error Messages:
Compiling SPLAT!…

In function ‘char* strncat(char*, const char*, size_t)’,
inlined from ‘int LoadSDF_SDF(char*)’ at splat.cpp:1663:
/usr/include/bits/string3.h:153: warning: call to char* __builtin___strncat_chk(char*, const char*, long unsigned int, long unsigned int) might overflow destination buffer

In function ‘char* strncat(char*, const char*, size_t)’,
inlined from ‘int LoadSDF_BZ(char*)’ at splat.cpp:1896:
/usr/include/bits/string3.h:153: warning: call to char* __builtin___strncat_chk(char*, const char*, long unsigned int, long unsigned int) might overflow destination buffer

Done!

Compiling SPLAT! HD…

In function ‘char* strncat(char*, const char*, size_t)’,
inlined from ‘int LoadSDF_SDF(char*)’ at splat.cpp:1663:
/usr/include/bits/string3.h:153: warning: call to char* __builtin___strncat_chk(char*, const char*, long unsigned int, long unsigned int) might overflow destination buffer

In function ‘char* strncat(char*, const char*, size_t)’,
inlined from ‘int LoadSDF_BZ(char*)’ at splat.cpp:1896:
/usr/include/bits/string3.h:153: warning: call to char* __builtin___strncat_chk(char*, const char*, long unsigned int, long unsigned int) might overflow destination buffer

Compiling srtm2sdf…

In function ‘strncat’,
inlined from ‘LoadSDF_SDF’ at srtm2sdf.c:264:
/usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer
In function ‘strncat’,
inlined from ‘LoadSDF_BZ’ at srtm2sdf.c:371:
/usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer


splat.cpp

Problem:
Building with parameter (8) 8 x 8 Degrees ——— 3330 Megabytes minimum”
sets the following in hd-parms.h
#define MAXPAGES 64
and causes compiler link errors:
collect2: ld returned 1 exit status

Explanation:
For some reason the branches are too large for the opcode field. (Don’t know enough about the GCC compiler at this time to explain in more detail.)

Solution:
Use a smaller build parameter. (6) worked for me.

Output of the faultly build:
Compiling SPLAT! HD… /tmp/cc0XOrhm.o: In function `LoadDBMColors(site)’:
splat.cpp:(.text+0x2cc): relocation truncated to fit: R_X86_64_PC32 against symbol `region’ defined in .bss section in /tmp/cc0XOrhm.o
splat.cpp:(.text+0x2d6): relocation truncated to fit: R_X86_64_PC32 against symbol `region’ defined in .bss section in /tmp/cc0XOrhm.o
splat.cpp:(.text+0x2ff): relocation truncated to fit: R_X86_64_PC32 against symbol `region’ defined in .bss section in /tmp/cc0XOrhm.o

splat.cpp:(.text+0×343): relocation truncated to fit: R_X86_64_PC32 against symbol `region’ defined in .bss section in /tmp/cc0XOrhm.o
splat.cpp:(.text+0x34a): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status


srtm2sdf.c

Problem:
Same buffer overrun complaint as splat.cpp

Solution:
Same solution: double the size of path_plus_name[255] to [512] in two places:
Line 264 modified char path_plus_name[512]
Line 371 modified char path_plus_name[512]

Build Error messages:
Compiling srtm2sdf… In function ‘strncat’,
inlined from ‘LoadSDF_SDF’ at srtm2sdf.c:264:
/usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer
In function ‘strncat’,
inlined from ‘LoadSDF_BZ’ at srtm2sdf.c:371:
/usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer

Links >

Categories: Linux Misc Tags:

TV Bands White Space – Petitions for Reconsideration

April 1st, 2009 jesse No comments

spectrum monitoring

The following is a brief summary of what each request for reconsideration would like to have changed and a link to the online petition.

Petitioners Seeking Greater Incumbent Protection

(pdf) Richard Rudman & Dane Ericksen

  1. There’s no value to the spectrum as once low power TV and other services migrate “in-core”, the amount of available spectrum will be too little to be useful, e.g., from the Commission’s Consolidated Data Base System – NYC has one available channel, DC has 1 but it’s not allowed due to land mobile considerations, Chicago has 2 which are again not available due to land mobile considerations, LA has no available channels… and so on.
  2. Testing was not “real-world”
  3. Currently TV interference is not investigated and it seems unlikely that this will change.
  4. There needs to be a criteria for “professionally installed”
  5. Two channels for wireless mic protection are too few
  6. Contour calculations are incorrect
  7. Polarization discrimination assumption is wrong
  8. Need tamper-proof devices and testing of tamper-resistance
  9. Protected users should be able to access their database entries free of charge

(pdf) Society of Broadcast Engineers

  1. 40 mW for portable devices are too high
  2. Reject calls for variable power levels
  3. Should test for interference to mobile video services
  4. Address errors /amibuigities in the report (wants minimum BW of 4.5 MHz, all power measurements based on 6 MHz BW, base height on HAAT)
  5. Do not allow spectrum sensing only approaches due to flaws + make sensing requirements more rigorous
  6. Should only be 1 database manager; database communications should be secured
  7. Permit fixed CPE as client to fixed WISP BS + protect these services from portable devices
  8. Protect all incumbents (e.g., satellite pickup, local broadcast)
  9. -114 dBm is inadequate (want -122 dBm)
  10. Want real-world testing
  11. Eliminate the ability to operate for more than 24 hours without an pdate from the database
  12. Want new devices to pay for cost of incumbents updating the database

(pdf) Barry Bynum

Expand the number of protected mic channels beyond 2.

(pdf) Shure

  1. Need rigoirous testing / certification procedures defined, with enhanced testing or spectrum sensing devices
  2. Adjacent channel operations will be harmful and should be prohibited or limited
  3. Wants -114dBm requireemnt to be satisfied in real-world situations (strong interferers on adjacent channels)
  4. Wants a 2 km buffer zone around wireless mics for fixed devices
  5. Wants modification to geolocation database for polling at least once every hour
  6. Wants ALL wireless mics protected from interference

(pdf) Community Broadcasters Association

Enhance protections for analog low power tv by

  1. Reducing “the maximum power level by 9 dB for unlicensed portable devices operating on an upper first adjacent-channel and by 14 dB for operation on a lower first-adjacent channel, where minimum mileage separations are not met.”
  2. Increasing “the minimum mileage separation where the protected station is analog and make such other adjustments as are appropriate to take into account the characteristics of analog TV broadcast receivers.”

(pdf) Cohen, Dippel and Everist

Unlicensed device signals could be picked up by indoor DTV antennas with amplification and cause harmful interference beyond what was originally anticipated.

(pdf) NCTA

  1. Current rules will allow for harmful direct pickup interference to cable services
  2. Inadequate protction to cable headends – protect all headends, regardless of location

(pdf) Dish Network / Direct TV

Ensure all multichannel Video Programming Distribution (”MVPD”) platforms (and not just cable heads) are afforded interference protection

Petitioners Seeking Greater Access

(pdf) Tribal Digital Village

  1. Relax the requirement that use of border (Mexico / Canada) spectrum is contingent on updated treaties
  2. Consider allowing lower power devices rather than an outright ban in border exclusion zones

(pdf) Motorola

  1. Allow for greater antenna heights
  2. Eliminate requirement for unregistered mic detection (”Depending on the location, between 50 to 90 percent of candidate TV band channels are unavailable due to spurious narrowband peaks”)
  3. Expand the set of adjacent channels via more precise prediction models (”As Motorola previously indicated, the restrictions on adjacent channel use impose a severe constraint on spectrum availability for WSDs, in many cases there will be no channels available for WSDs if restrictions on adjacent channels use is retained”)
  4. Allow for higher-powered geolocation based devices that are vehicle mounted
  5. Eliminate the transmission ID requirement
  6. Clarify emissions requirements

(pdf) Public Interest Spectrum Coalition

  1. Remove requirement for sensing when working from database
  2. Allow for greater transmission power levels in rural areas
  3. Wants all information in databases to be on the public record
  4. Wants at least one database to run by a non-profit
  5. Also wants databases to support signal measurements
  6. Wants a simpler TVBD certification process
  7. Allow for certification of devices at greater power levels
  8. Allow TVBD in channels 5-20
  9. Eliminate “professional installer” classification requirement

(pdf) 802

  1. fixed masters should be allowed multiple fixed clients,
  2. sensing should be optional when database is available,
  3. adjust the antenna height and PSD requirements,
  4. knock down microphone sensing to -107 dBm (instead of -114)\
  5. Allow for near-real-time database access

(pdf) WiFi Alliance

Repeats most of the 802 recommendations

(pdf) Adaptrum

  1. Only protect legal wireless mics
  2. -114 dBm is too low for wireless mics
  3. Should only really protect safe-harbor TV bands
  4. Transmit power levels on TVBD are too stringent – allow for flexible PSD
  5. Should consider terrain in coverage maps
  6. Want transmitter ID standardized now
  7. Explain cable head requirements

(pdf) Key Bridge

  1. Databases need secure access requirements
  2. Fear transmitter ID approach allows for forged identification
  3. Wants devices to be mandated to report sensing information to databases
  4. Wants clarity / simpler method of charging for access to database
  5. Wants mandate for devices to report the current operating channels
  6. Wants to ensure that FCC’s power to delete / remove information from database is limitd to information provided by the FCC

(pdf) Dell & Microsoft

  1. Eliminate sensing requirements when databases are available, or reduce to -107 dBm
  2. Allow operation below Channel 21 for personal / portable devices
  3. Cable-head protection should only extend to those channels the cable-heads actually receive over-the-air and only to local channels (”must-carry” channels)

(pdf) Wireless Internet Service Providers Association

  1. Elimiate sensing requirements for fixed networks (”As written, the sensing rules render white spaces unusable for fixed broadband…..In sum, by mandating unproven spectrum sensing requirements, the Commission has essentially banished WISPs from the TV white spaces”)
  2. Barring that, relax sensing requirements – no omnidirectional, two second vacation is too burdensome, vacation for only a single detection is too burdensome
  3. Allow greater antenna heights
  4. Allow for sliding power levels as distance from incumbents increase
  5. Non-interference requirements should extend to fixed TVWS networks

(pdf) New America Foundation

  1. Do not reopen licensed vs unlicensed debate
  2. Allow mobile devices in channels 14-20
  3. Allow devices before end of DTV transition

Other Petitioners

(pdf) SprintNextel et al.

Some of the spectrum should’ve gone for fixed, licensed use (specifically 6 channels in rural areas and third or greater adjacent channels in any market) either for present or future use.

References >

Categories: Wireless Tags: