Monday, 20 December 2010

BIND9 error: dumping master file: slave/tmp-XN31Wp2BeK: open: file not found

Problem: BIND9 error: dumping master file: slave/tmp-XN31Wp2BeK: open: file not found

BIND is by far the most widely used DNS software on the Internet. It provides a robust and stable platform on top of which organizations can build distributed computing systems with the knowledge that those systems are fully compliant with published DNS standards.
BIND is available for free download under the terms of the ISC License, a BSD style license.
In FreeBSD, the BIND daemon is called named.

Secondary - slave name Server.
The purpose of a slave name server is to share the load with the master server, or handle the entire load if the master server is down. A slave name server loads its data over the network from another name server, usually the master name server, but it can load from another slave name server too. This process is called a zone transfer.

The purpose of this article is to clarify the problem in a standard installation.
A slave DNS server after setup wasn't able to transfer a zone file while I used working config file from another FreeBSD box.

Upgrade of all related packages from fresh ports and installed (reinstalled base) BIND.

Check points:

1 - check master (authoritative) name server
Enable the master for transfer and notify zone for your slave server.
edit master /etc/namedb/named.conf

2 - check the zone information is transferred
Check if the slave name server will have the transferred zone information and will be able to serve it.

dig AXFR
we requesting @master transfer ZONE-FILE
[root@server]# dig @ns1 AXFR

; <<>> DiG 9.6.-ESV-R2 <<>> @ns1 AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.
The masters log:
bad zone transfer request: '': non-authoritative zone (NOTAUTH)
A typo mistake, while I asked wrong domain name.

[root@server]# dig @ns1 AXFR
; <<>> DiG 9.6.-ESV-R2 <<>> @ns1 AXFR
; (1 server found)
;; global options: +cmd          7200    IN      SOA 2010071701 36000 36000 1209600 36000          7200    IN      NS          7200    IN      NS
--^-snap -^--
-^--snap ^--^
;; Query time: 866 msec
;; WHEN: Fri Dec 17 17:57:09 2010
;; XFR size: 13 records (messages 1, bytes 384)

3 - check slave transfer

Zone was transferred that's OK so far, however slave server still complaining.

general: info: zone Transfer started.
xfer-in: info: transfer of '' from connected using
general: error: dumping master file: slave/tmp-w04S0tBOCA: open: file not found
xfer-in: error: transfer of '' from failed while receiving responses: file not found

Mr google says: the permissions are wrong... NOT
True is that slave zones require a writeable directory for BIND automatically creates and writes to the slave zone file.

[root@server /var]# chown -R bind:wheel named/ -- do not help
and chmod 777 slave/ - NOT recommended

[root@server]# /etc/rc.d/named start
. changed
user expected 0 found 53 modified
dev changed
user expected 0 found 53 modified
etc changed
user expected 0 found 53 modified
etc/namedb changed
user expected 0 found 53 modified
etc/namedb/master changed
user expected 0 found 53 modified
etc/namedb/slave changed
permissions expected 0755 found 0777 modified
var changed
user expected 0 found 53 modified
Starting named.

Surprise is that the BIND doing it's job thoroughly. It starts and do a permissions check (and change).

4 - solve the problem
CORRECT named.conf at the slave server

DO NOT (at present time) believe in the FreeBSD handbook:

********** named.conf - wrong example ***************
zone "" {
type slave;
file "slave/";
********** named.conf - wrong example ***************
Here the zone information is transferred from the master name server for the particular zone, and saved in the file specified

According mailing list, it's known problem that some entries in the FreeBSD handbook are outdated.

Edit and FOLLOW an example slave zone named.conf for actual version of BIND.

[root@server]# vi /var/named/etc/namedb/named.conf

********** named.conf - working slave zone ***************
zone "" {
type slave;
file "/etc/namedb/slave/";
masters {;
********** named.conf - working slave zone ***************

5 - last checks
Restart BIND and check logs
/etc/rc.d/named restart

The DNS slave server works now:
-^--snap ^--^
info: zone transferred serial 2010071701
info: transfer of '' from Transfer completed: 1 messages, 13 records, 384 bytes, 0.614 secs (625 bytes/sec)
info: zone sending notifies (serial 2010071701)
-^--snap ^--^

External DNScheck may be usefull too.
(sometimes a firewall may block incoming queries)


DNS and BIND, Fifth Edition
man named - Domain Name System (DNS) server

Comments and corrections of this article are welcome :)

Monday, 13 December 2010

Streaming video over wireless network(s)

I was asked to create a small wireless network for 16 clients/students (guess NIC 802.11g) to watching video streams.

With file sharing or web browsing we may wait for file or web page few seconds, however is not fun, when video stream stops often and repeatedly.

The very first question they asked me: How many routers we need?

Well question was simple, but we did talk about video where video presents many chalenges for:

- server file system (SMB for other 60 clients)
- AP congestion
- Wireless interference, speed and distance (video stream may stop)
- latency, packet loss and delays (video stream may stop)

I don't like guess. Whether two or twenty of AP could by enough?
In spite of all I found very nice article which nice explains all of my concerns about reliability WiFI Access Points concentrated nearby.

Network Video Overview
Traditional analog video is sent as a continuous stream of electrical signals over a cable from the source (camera) to the destination such as a video monitor in a command center. Digital technology and IP has changed that. With this new type of video, a digital camera translates the viewed image into digital signals which it then converts (encodes) into a series of IP packets that can be sent out over an IP-based network as a data stream. The IP network may be a local area network, a company wide area network, or even the public internet. At the destination, the receiver re-assembles these packets back into the original video stream. The reconstructed video can then be viewed, stored, searched, replayed, or retransmitted to virtually any location anywhere in the world.

This sounds simple, but IP video is a totally new area with significant technological and integration challenges. Unlike other types of data, video requires large amounts of bandwidth, as well as highly reliable, predictable delivery mechanisms. Unfortunately, IP was not designed to provide this guaranteed quality of service (QoS) to the different types of traffic it carries and frequently one or more packets may be dropped during transmission. For bulk data transmissions such as file transfers, this is effectively managed by re-transmitting the dropped packets and reinserting them into the data; however, for applications such as video, packet re-transmission is a poor option since the missing packets are required to accurately reproduce the video image. Unmanaged, these factors cause latency and jitter, which result in poor quality or even unusable video at the receiving end.

Wireless Network Challenges
While latency and jitter is minimal in a wired network, wireless networks are quite different. Because of the uncertainty in the wireless medium, Wireless LAN (WLAN) networks employ a variety of techniques in attempt to overcome these problems. When a packet is to be transmitted, the sender first listens for any activity on the frequency, and if there is none, waits a random amount of time before transmitting. This methodology is called Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA). If an acknowledgement (ACK) is not received, either due to interference, collision, or other anomaly, the entire process is repeated. This protocol enhances the reliability of the WLAN network, however, this process also adds jitter and latency to the video traffic which can produce poor quality video or total loss of continuity. The WLAN process also includes a request to send/clear to send (RTS/CTS) mechanism which is used to decrease the chance of collision on a system by making sure that end stations in the vicinity of the source and destination hear the RTS and CTS signals before sending actual data packets. While this mechanism increases robustness it also adds to the latency of packets.

Packet Errors, Latency, Delay and Jitter – Why Video and Wireless Don’t Mix
Low, predictable and consistent latency is key for running video applications over networks, regardless of the available bandwidth; large amounts of bandwidth does not guarantee high quality video. While most wired IP networks can support this requirement, wireless networks are extremely susceptible to errors, which ultimately result in packet loss and packet errors. In many wireless networks a 20% to 40% packet loss is not uncommon. While the built-in mechanisms described above can prevent or recover from some amount of packet errors, each retransmission creates up to 4 ms of additional latency and up to 16 retransmissions can be required per packet error. This process results in unacceptable levels of latency, delay and jitter, which is seen as frozen, jerky, or pixilated video on the viewing screen. In extreme cases, video transmission can stop altogether until the video stream is re-synchronized with the receiver. This is clearly unacceptable for commercial video surveillance applications.

Factors Contributing to Packet Errors, Latency, Jitter, and Delay

Interference is the predominate cause of packet errors and loss in wireless networks. While the automatic packet recovery process used in typical networks may help, this process introduces increased latency, delay, and jitter which can compromise video quality and reliability. Following is a brief summary of the most common causes of problems in wireless networks.

Direct spectrum interference and noise
The most obvious source of interference, this occurs when other wireless elements are set up on the same, or overlapping, frequencies or when other devices create radio frequency waves (RF) that conflict with those of the wireless device. For example, microwave ovens, portable telephones, and bluetooth devices can produce RF waves (noise) that interfere with many wireless communications systems.

Near-angle interference
Near-angle interference is a form of direct spectrum interference that can happen when there are 2 or more point-to-point shots with two centrally located antennas arranged physically close to one another. For example, a campus environment where multiple remote buildings have point-to-point shots back to a central building. The transmitted signals from one antenna supporting a point-to-point link can interfere with it’s adjacent antenna.

Multipath and Reflection
Multipath and reflection are two related types of interference that usually occurs when parts of a transmission beam are refracted from objects (e.g., glass, water, furniture, metallic surfaces) between the sending and receiving radios causing the signals to be received a different times or severely attenuated. The refracted beams are received by the receiving radio at different and the radio gets confused. Multipath interference is likely to occur in large enclosed environments such as warehouses and manufacturing facilities or when used in proximity to large reflective objects such as high-rise buildings.

Other contributing factors
Beyond interference, other factors such as congestion and bandwidth limitations can also cause packet loss and produce unacceptable levels of delay and jitter in wireless video applications.  The delay in the IP network is caused by propagation delay in the transmission lines, buffers in routers, and jitter buffers. Transmission delay is split into two parts: a constant or slowly varying network delay and rapid variations referred to as jitter. Because of the nature of the IP network, the amount of delay is different in each direction.

The jitter present in packet networks complicates the decoding process in the receiver device because the decoder needs to have packets of data readily available at the right time instants. A jitter buffer is normally used to make sure that packets are available when needed, resulting in additional delay that increases with the magnitude of the jitter.  Packet loss occurs either if a packet is lost in the network or if a packet arrives too late to be handled by the decoder. By allowing for a long delay in the jitter buffer, the latter type of packet loss can be almost completely removed, but at the price of increased system delay. For real time video surveillance applications, this solution is unacceptable.

Implications for Wireless LANS
The lossy nature of the 802.11 medium amplifies the effects of these factors. The challenges in deploying Video over WLAN stem mainly from issues related to access point congestion and link quality. This is particularly relevant when multiple video sources are connected to the same access point. The efficiency of the system quickly deteriorates when the number of users increases, resulting in significantly higher delay, network jitter, and packet loss than wired LANs.

As we have seen, high quality full motion video delivery over ordinary wireless links is a complicated problem because of dramatic and frequent changes in the quality of the underlying wireless channel. This is further complicated by latency constraints and typical TCP/IP protocol processing overhead, which often results in poor quality or unusable video. There are some interesting technolgies that are able to overcome much of the packet loss seen in wireless networks to deliver high quality video regardless of network anomalies...