Lines Matching full:address
32 data obtained via TCP is not cached, and source-address
36 no IP address and are for names like mymachine.mydomain.com.mydomain.com.
40 an upstream nameserver to resolve that address and it replied "doesn't
70 IP address of that server, and telling dnsmasq exactly which
76 A: Use the standard DNS convention of <reversed address>.in-addr.arpa.
84 failed: Cannot assign requested address". What's the problem?
88 created, but not brought up and assigned an address. The easiest
150 domain) return the address of a host at Versign which runs a web
158 host returns an IP address, then the DNS is broken. (Try a few
163 note the IP address being returned and pass it to dnsmasq using the
165 that address and substitute an NXDOMAIN instead.
167 As of writing, the IP address in question for the .com and .net
182 The first thing to check is the broadcast address set for the
185 address of the ethernet interface is 192.168.55.7 and the netmask
186 is 255.255.255.0 then the broadcast address should be
187 192.168.55.255. Having a broadcast address which is not on the
197 address 0.0.0.0 and destination address 255.255.255.255 are not
200 Q: I'm running Debian, and my machines get an address fine with DHCP,
212 DHCP-assigned addresses. The machine gets its correct address
214 allocated a different address.
217 request and gets allocated the static address corresponding to its
218 MAC address. The boot loader does not send a client-id. Then the OS
222 the MAC address has a static allocation, that address is still in
225 dynamic address from its pool. There are three ways to solve this:
227 the static assignment to the client ID, not the MAC address. The
228 default client-id will be 01:<MAC address>, so change the dhcp-host
231 ignore client IDs for a particular MAC address, like this:
242 same address it was sent to. The traditional way to write an UDP
245 socket for each interface which is bound to the address of the
246 interface. Then when a packet is sent to address A, it is received
247 on the socket bound to address A and when the reply is also sent
248 via that socket, the source address is set to A by the kernel and
252 --interface, --address and --except-interface flags. The
259 to the correct port and the wildcard IP address (0.0.0.0). That
261 destination address they have. This solves the problem of
264 "reply source address" problem. When a UDP packet is sent by a
265 socket bound to 0.0.0.0 its source address will be set to the
266 address of one of the machine's interfaces, but which one is not
269 address to which a query was sent, and force that to be the source
270 address in the reply. For IPv4 this stuff in non-portable and quite
277 It could be argued that if the --interface or --address flags are
284 (address,port) pair when dnsmasq has bound (wildcard,port), hence
325 MAC address, which is associated with interface hardware. Once an
326 IP is bound to the MAC address of one interface, it cannot be
327 associated with another MAC address until after the DHCP lease
329 identity rather than the MAC address. If you arrange for the same
331 will recognise the same machine, and use the same address. The
338 address in a --dhcp-host configuration. This tells dnsmasq that it
354 If a physical interface has more than one IP address or aliases
356 these addresses can be used for address allocation. So if an
361 have one of the address-ranges as static-only, and have known
386 assumes that the address is in use, and attempts to allocate an
387 different address. The wait for a reply is between two and three
390 the address probe may be skipped when dnsmasq is under heavy load.
