Dhcp для mac os

Использование DHCP или ввод IP-адреса вручную на Mac

IP-адрес — это номер, идентифицирующий каждый компьютер в Интернете или сети. Когда Вы подключаетесь к Интернету или IP-сети, компьютеру требуется IP-адрес.

Есть два основных способа, с помощью которых можно задать IP-адрес.

Автоматически: Вашему компьютеру назначается адрес с помощью протокола DHCP.

Вручную. Ваш интернет-провайдер или сетевой администратор предоставляет IP-адрес, который необходимо ввести на панели «Сеть» в Системных настройках.

Выполните описанные ниже действия, чтобы ввести свой IP-адрес или назначить его автоматически.

На Mac выберите меню Apple

> «Системные настройки», затем нажмите «Сеть».

Выберите сетевое подключение, которое хотите использовать, в списке (например, Ethernet).

Нажмите всплывающее меню «Конфигурация iPv4» и выберите нужный вариант:

Если Ваш адрес назначается автоматически, выберите «Использовать DHCP».

Если интернет-провайдер или администратор предоставил Вам IP-адрес, выберите «Вручную» и введите адрес в поле «IP-адрес». Поставщик услуг сети Интернет предоставляет DHCP-адрес вместе с прочей информацией, например маской подсети, маршрутизатора и сервера DNS (служба доменных имен). Укажите маску подсети и маршрутизатор в соответствующих полях. Чтобы ввести адрес DNS-сервера, нажмите «Дополнительно», откройте вкладку «DNS», затем нажмите кнопку и введите адрес.

Примечание. Большинство IP-адресов — это адреса IPv4, которые выглядят как серия чисел, разделенных тремя точками, например: 123.45.67.89. Если Вы получили IP-адрес с более длинной последовательностью чисел и букв, разделенных семью точками (например, fa80:0000:0000:0123:0203:93ee:ef5b:44a0), то это другой тип IP-адреса, который называется IPv6. Чтобы ввести адрес IPv6, в разделе настроек «Сеть» нажмите «Дополнительно». В TCP во всплывающем меню «Конфигурация IPv6» выберите «Вручную» и введите адрес IPv6.

Источник

Как настроить автоматическое получение IP-адресов (по DHCP) на MAC OS?

Для установки и настройки устройства TP-Link в первую очередь необходимо настроить автоматическое получение IP-адреса от роутера – чтобы компьютер мог получить правильный IP-адрес от устройства TP-Link. Данная настройка так же позволяет вашему ПК автоматически устанавливать большинство сетевых параметров.

Шаг 1. Нажмите на иконку Apple в левом верхнем углу, в выпадающем меню выберите раздел Системные настройки.

Шаг 2. Нажмите на иконку Сеть.

Шаг 3. В левой колонке выберите сеть Ethernet (проводное подключение) или Wi—Fi (беспроводное) в зависимости от того, к какой сети подключён ваш компьютер. Нажмите кнопку Дополнительно.

Шаг 4. Откройте раздел TCP/IP. В выпадающем списке конфигурация IPv4 выберите использовать DHCP. Нажмите кнопку ОК.

Источник

Question: Q: Setting up Mac OS X as a DHCP server

I want to be able to sit on a plane and connect my Raspberry Pi to My Mac on a private local network for software development on the Pi.

I have tried to follow this to set it up but failed (my ip address was still an unassigned one) —

Can anyone point me at an idiot proof guide to doing just this please.

MacBook Pro with Retina display, OS X Yosemite (10.10.2)

Posted on May 4, 2015 7:17 AM

Helpful answers

I think you were missing my point. You cannot switch on wifi in a plane. But even putting that aside I want a wired connection as I find wifi rather erratic on a Pi.

Yea, I think several of us were not clear on that point, and our natural bias for using WiFi dominated our brains 😊

If you use Applications -> Utilities -> Terminal -> ifconfig (After connecting the Pi to the Mac via Ethernet), does the Ethernet device (typically en0) have a self-assigned IP address (169.254.x.x) that you can use from your Pi to make a connection?

Or is this a matter of the Pi needing the DHCP server to pick its own IP address so that the Mac can connect and control the Pi ?

Can you just run «sudo /usr/libexec/bootpd -D -d -i en0» from a Terminal session? «man bootpd» for more information. This is apparently what Internet Sharing runs. If this works, then after you connect your Pi, you can use ifconfig to see what IP address was assigned to en0 (I think).

Applications -> Utilities -> Console -> system.log should contain any error messages from /usr/libexec/bootpd

At the moment I’m sitting in a coffee shop with ONLY my Macbook Pro to play with, and no other computer systems I can attach to see if my guesses work.

May 5, 2015 6:16 AM

There’s more to the conversation

Loading page content

Page content loaded

At first glance, the most obvious missing component in that page you linked to is any discussion about your Mac’s own IP address.

The article seems to be valid to setup a DHCP server to hand out addresses in the range 192.168.222.2-254 via en0. I would expect the Pi to connect as long as it’s on the same physical network, so things to check:

1) are you sure ‘en0’ is the right interface on your Mac? is your Pi connecting wirelessly or wired?

2) the server advertises 192.168.222.2-254, but the article doesn’t mention that it’s only practical if your Mac’s interface is set to 192.168.222.1. Is that the address you’ve assigned your Mac? If your Mac is in a different subnet then it’s not going to work.

There may be other considerations, but I’d start with these two.

May 4, 2015 11:21 AM

What I’d do is enable a hotspot on one of your devices. For the mac, here is a write-up:

May 4, 2015 11:29 AM

Just wondering if you have tried «Create Network. » from the WiFi menu? This is suppose to create a ad-hoc network for point-to-point connection between 2 computers.

May 4, 2015 11:31 AM

What I’d do is enable a hotspot on one of your devices. For the mac, here is a write-up:

I often use the ad-hoc network feature. However, I did say in my OP I want to sit on a plane — while it is airborne 🙂

May 4, 2015 12:20 PM

Just wondering if you have tried «Create Network. » from the WiFi menu? This is suppose to create a ad-hoc network for point-to-point connection between 2 computers.

See my reply above

May 4, 2015 12:20 PM

At first glance, the most obvious missing component in that page you linked to is any discussion about your Mac’s own IP address.

The article seems to be valid to setup a DHCP server to hand out addresses in the range 192.168.222.2-254 via en0. I would expect the Pi to connect as long as it’s on the same physical network, so things to check:

1) are you sure ‘en0’ is the right interface on your Mac? is your Pi connecting wirelessly or wired?

2) the server advertises 192.168.222.2-254, but the article doesn’t mention that it’s only practical if your Mac’s interface is set to 192.168.222.1. Is that the address you’ve assigned your Mac? If your Mac is in a different subnet then it’s not going to work.

There may be other considerations, but I’d start with these two.

1. That’s a good point. When I do «ls /dev» from a Terminal I don’t see en0 — however I don’t see any ethernet devices, even though the ethernet connection is fine and working.

2. I rather assumed that I leave the Mac in DHCP mode. I’ll try that.

May 4, 2015 12:24 PM

I would not expect being on a plane would make a difference. I do not think the uplink has to be active. I’ve only done it with an active uplink.

But, I’ll defer to the other posters.

May 4, 2015 12:29 PM

I would not expect being on a plane would make a difference. I do not think the uplink has to be active. I’ve only done it with an active uplink.

But, I’ll defer to the other posters.

I think you were missing my point. You cannot switch on wifi in a plane. But even putting that aside I want a wired connection as I find wifi rather erratic on a Pi.

May 4, 2015 12:55 PM

I think you were missing my point. You cannot switch on wifi in a plane. But even putting that aside I want a wired connection as I find wifi rather erratic on a Pi.

Yea, I think several of us were not clear on that point, and our natural bias for using WiFi dominated our brains 😊

If you use Applications -> Utilities -> Terminal -> ifconfig (After connecting the Pi to the Mac via Ethernet), does the Ethernet device (typically en0) have a self-assigned IP address (169.254.x.x) that you can use from your Pi to make a connection?

Or is this a matter of the Pi needing the DHCP server to pick its own IP address so that the Mac can connect and control the Pi ?

Can you just run «sudo /usr/libexec/bootpd -D -d -i en0» from a Terminal session? «man bootpd» for more information. This is apparently what Internet Sharing runs. If this works, then after you connect your Pi, you can use ifconfig to see what IP address was assigned to en0 (I think).

Applications -> Utilities -> Console -> system.log should contain any error messages from /usr/libexec/bootpd

At the moment I’m sitting in a coffee shop with ONLY my Macbook Pro to play with, and no other computer systems I can attach to see if my guesses work.

May 5, 2015 6:16 AM

I think you were missing my point. You cannot switch on wifi in a plane. But even putting that aside I want a wired connection as I find wifi rather erratic on a Pi.

Yea, I think several of us were not clear on that point, and our natural bias for using WiFi dominated our brains 😊

If you use Applications -> Utilities -> Terminal -> ifconfig (After connecting the Pi to the Mac via Ethernet), does the Ethernet device (typically en0) have a self-assigned IP address (169.254.x.x) that you can use from your Pi to make a connection?

Or is this a matter of the Pi needing the DHCP server to pick its own IP address so that the Mac can connect and control the Pi ?

Can you just run «sudo /usr/libexec/bootpd -D -d -i en0» from a Terminal session? «man bootpd» for more information. This is apparently what Internet Sharing runs. If this works, then after you connect your Pi, you can use ifconfig to see what IP address was assigned to en0 (I think).

Applications -> Utilities -> Console -> system.log should contain any error messages from /usr/libexec/bootpd

At the moment I’m sitting in a coffee shop with ONLY my Macbook Pro to play with, and no other computer systems I can attach to see if my guesses work.

Thanks for all your input. I have now got it working by simply fixing my ip address at both ends (192.168.0.x), I seem to have been making heavy weather of it ! The problem I had as that for some reason it takes about 10-15 seconds before it responds to an SSH command and I was being too impatient.

Источник

Dhcp для mac os

Last updated 2008/03/18

Introduction

The Dynamic Host Configuration Protocol (DHCP) is a mechanism for automatically configuring networked computers from a centralized server. Usually, DHCP is used to provide IP addresses to clients without their needing to know anything about the network they are connected to. With more configuration, DHCP can also be set up to provide a rich set of information to clients, from routers to DNS servers all the way up to LDAP providers and diskless bootstrap information.

At Suffield, we use DHCP to automatically assign IP addresses to computers on our network. Because most of our users own laptops, we have the additional challenge of users changing locations (and thus, subnets) frequently. DHCP is used to not only hand out the proper IP address for each client, but also provide subnet- and LAN-specific information to each client so that they can connect to the network without requiring intervention by the user.

Mac OS X Server Setup

We run DHCP service on machines running Mac OS X Server 10.4. Mac OS X Server comes with its own built-in DHCP server. This server can be configured via the Server Admin GUI, and is also integrated into Apple’s NetBoot services.

Unfortunately, Apple’s DHCP server does not yet implement all of the features we need in a DHCP server, including dynamic DNS updates, failover, and known/unknown client grouping.

For this reason, we choose to install the ISC DHCP server on our Mac OS X Server machines, and configure it as we would on any other standard UNIX machine. (Note that this config would work equally well on a UNIX box, as the version of the ISC server is the same for all platforms.)

Getting dhcpd from DarwinPorts

DarwinPorts is a collection of ready-to-compile software for Mac OS X. If you have not yet installed DarwinPorts, please see our section describing the installation of DarwinPorts. (The section discusses the installation of Subversion, but the DarwinPorts information is not specific to that package.)

Once you have DarwinPorts installed, you simply need to install the dhcp port:

DarwinPorts will download, unpack, configure, compile, and clean the distribution for you automatically. When done, you should be able to run the following:

You should get the standard help screen for DHCP. If you do, then the binaries are installed, and you’re ready to move on.

Note: as part of the installation process, DarwinPorts creates a new StartupItem called DarwinPortsStartup. This item then bootstraps any installed daemons under the DarwinPorts system. In its default state, no services are launched, so the item won’t do any harm. We use Mac OS X 10.4 (Tiger), so we will configure launchd to start the DHCP server instead.

Suffield DNS Config Template

To make setting up DHCP servers easier, we have broken our standard DHCP config into several include files, along with a «primary» and «secondary» configuration template file. Taken together, these files can be quickly pieced together to form a functioning primary or secondary DHCP server.

The files are stored in revision control, and can also be viewed directly from the web:

For servers, we recommend checking the files out of version control. This way, changes to the files can be easily synched up using our version control software.

Differences

Our configuration is broken up into several different files, which makes it easy to plug in different functionality for different servers while maintaining a consistent set of global options. The primary and secondary configs simply include these core options, and only add the small changes required for the symmetry in a failover pair.

In the file segments themselves, these are the major pieces of functionality we implement:

A global options file, which contains all of the server-wide option settings (nameservers, domain names, default lease times, etc.).

A ddns options file, which covers all settings related to Dynamic DNS updates (DDNS).

A zones file, which contains all of the forward and reverse DNS zone declarations used by DDNS.

A keys file, to hold DNSSEC keys to digitally sign DNS updates.

A series of clients files, which contain the static host declarations for known clients.

A common file, which ties together all of these options into a single master file.

Primary and secondary files, which add the necessary statements for failover operation. These are the files you should use as your main dhcpd.conf file on a server.

Using the Configuration

To use our base configuration, follow these steps:

Check out the stock config from our Subversion repository:

The command above checks out the stock directory to the name dhcp.d . You may choose a different name for the directory, but you will need to change all of the include statements in the config file to reflect the new path.

If you’re using DNSSEC (which we do), you’ll need to create an include file with all the DNSSEC keys in it. First, copy our template config:

Then, edit the file and add any keys that are needed for inter-server communication.

Our configuration is designed for failover operation, so there are two files to choose from: primary.conf and secondary.conf . Link the appropriate file to /etc/dhcpd.conf :

DHCP will not start until you’ve created an empty lease file for it. This is to prevent errors if you accidentally move the lease file out of the way for manual recovery:

Our DHCP config is set to log via the syslog logging facility under UNIX. However, many systems are not configured to «listen» for these log announcements. To fix this, edit /etc/syslog.conf and add the following line:

(You may use a different log level facility if you wish; info prints all lease transactions and may be too verbose for some users.)

You will need to kill and restart the syslogd daemon for these changes to take effect.

1. Finally, copy the LaunchDaemon plist file for DHCP into the server’s /Library/LaunchDaemons/ directory. You can download the file from our DHCP LaunchDaemon repository.

At this point, you are ready to start the DHCP server:

Check the system logs to see if the server reports any errors. You may confirm that the service is running by typing:

The org.isc.dhcpd identifier should appear if everything is running properly. Check the /var/log/dhcpd.log file to confirm that the server has started (it should print informational messages on startup).

Using DHCP

Once DHCP is installed and configured, you are ready to run the daemon in a production environment. Normally, you won’t need to interfere with the daemon’s operation; it should serve requests normally without need for restart or reconfiguration.

From time to time, you will need to reconfigure the server. Normally, this is done to add hosts to the database that have specific names or IP addresses.

Normal Operation Indicators

When the server is working properly, you will see entries in the log like this:

In this case, a client has broadcast that it wants an address (DISCOVER), the server has made an offer (OFFER), the client confirms the offer by requesting the specific address (REQUEST), and the server confirms that the address is available for use (ACK).

Later, when clients already have an address, they will renew the address by performing the final two steps again (REQUEST/ACK).

You may occasionally see deny messages (DHCPNACK). These are not cause for concern; normally they are sent to clients that have moved between subnets and no longer have a valid address for the subnet they are on. The server sends a negative ACK, and the client begins the negotiation process anew to get a proper address.

Finding a Client’s Address

If you ever need to find the MAC address that goes with an IP address (or vice-versa), just grep the log file for the IP or MAC address. The last matching entry will be the assignment made by the server.

Starting the Daemon

If you’re using Mac OS X Server 10.4, the DHCP server should start itself via launchd if you’ve installed our LaunchDaemon item. If you’ve manually stopped the service, you can start it again using:

The -w flag makes the load status permanent; that is, the server will continue to start the process from this point forward, even after a reboot of the machine.

If you use a regular UNIX system, launching dhcpd is usually accomplished using an /etc/init.d/ or /etc/rc.d/ script. Use the method described by your UNIX distribution.

Stoping the Daemon

If you’re using Mac OS X Server 10.4, you must use launchd to stop the daemon process (if you don’t, launchd will just start it back up for you). To do this, type the following:

The -w flag makes the unload status permanent; that is, the server will never start up again until you re-enable it with launchctl (even if you reboot).

If you use a regular UNIX system, stopping dhcpd is usually accomplished using an /etc/init.d/ or /etc/rc.d/ script. Use the method described by your UNIX distribution. If you’re in a pinch, you can also try killing the process directly. Assuming it isn’t being respawned by init , the DHCP server should exit and stop running.

Loading Configuration Changes

The ISC DHCP server does not have a «reload» option. Therefore, the only way to re-read the configuration files is to stop the server and start it back up again.

When you’ve made changes to the configuration and are ready for them to take effect, you should always test the configuration first:

Confirm that there are no errors reported before you restart the server.

If you’re using launchd to run DHCP (as we describe above), reloading the configuration is as simple as manually killing the process:

launchd will notice that the process has died, and will automatically restart it. Upon restart, the new configuration will be read, and your changes should take effect.

On systems that use a traditional start/stop mechanism, you can simply stop the server and start it immediately after, using the start and stop procedures described above.

Adding Fixed Hosts

While the DHCP server usually tries to give the same address to clients every time, there is no guarantee. Some hosts on the network should be given «fixed» addresses that never change (such as network equipment, appliances, and other vital equipment).

Note: «regular» clients can be given a name and parameters that don’t change, without needing to assign a specific IP address. If you’re adding a record for a user’s computer, please see the next section for information on how to add a host record with a dynamic address.

To ensure that a client gets a fixed address every time, follow these steps:

Create forward and reverse DNS entries for the client on your DNS server.

Edit the section of your configuration files where host declarations are kept. In our config, the host info is kept in the client_*.inc files. You should add a stanza that looks like this:

This tells the DHCP server to always associate the IP address that new-hostname.example.org resolves to with the given Ethernet MAC address.

Restart the server to reload the configuration.

Adding Registered Hosts

Under our configuration, the DHCP server knows about three types of clients: «fixed» clients that are given static IP addresses, «registered» clients that have some identifying information known about them, and «rogue» clients that are unknown to the server.

By default, all clients get addresses from the server, so it is not necessary to register a client before connecting it to the network. However, «registered» clients receive better treatment, in the form of (possibly) longer leases, dynamic DNS updates, and a larger pool of addresses.

Registered hosts should be used for any hosts that should receive a consistent name in DNS, but that might travel between subnets (and thus need a different IP at different times). It’s somewhat of a comprimise between «rogue» hosts and «fixed» hosts.

To add a registered host, follow these steps:

Edit the section of your configuration files where host declarations are kept. In our config, the host info is kept in the client_*.inc files. You should add a stanza that looks like this:

This tells the DHCP server to always associate the given DNS hostname with the given Ethernet MAC address. The Dynamic DNS (DDNS) features of the DHCP server will ensure that the client always gets the same DNS name, even if the IP address it resolves to changes.

Restart the server to reload the configuration.

Failover

Our default configuration employs a peered failover system to ensure reliable service. The ISC DHCP server supports the DHCP failover protocol with only minimal extra configuration.

This section gives a brief guide for using failover and recovering from disasters. For more detailed information, please see the manual page for dhcpd.conf and dhcpd .

For the most part, failover requires no intervention on the part of the administrator. When one server fails, the other notices (you’ll see a log message), and will attempt to service clients that were handled by the peer server.

For short outages (server reboots, configuration changes, etc), you don’t need to worry about failover. When the other machine comes back, it will automatically syncronize with the running server.

For long outages (days, weeks, months), you may wish to manually place the running server into partner-down mode. This tells the running server that its peer is known to be down, so it can take over full service for the network.

Getting In to the Partner-Down State

Note: if you place a server into partner-down mode, you must be absolutely sure that the peer is legitimately down, and not just out of contact with the server. If the failed server is still running, and the running server begins to take over its addresses, then both servers might hand out the same addresses to different clients.

If a peer in a failover setup fails, and you wish to have the surviving server take over all service for the network, follow these steps on the functioning server:

Read the man page for dhcpd(8), and search for the «local-state» parameter. Make note of the integer code for the «partner down» state. This value has changed over time in different releases, but as of this writing it was «4».

Using omshell , you’re going to update the functioning server so it is in the «partner down» state. This will cause it to take over leases from the peer. Use the following script (or run omshell and type the input in directly):

Note that the «suffield» name value is taken from the peer configuration file (e.g., primary or secondary — should be the same for both). And again, the «local state» value **must be taken from the current value found in dhcpd’s man page**.

The «open» line should show the current state, and the failover state should show the value for «communications interrupted» (3 as of this writing). After the «update», the value should read «4» (or whatever the correct value is).

1. Finally, check the dhcpd.log files and confirm that the server thinks its partner is in the partner-down state.

Over time, the running server will reclaim leases that used to be handled by the failed server.

Getting Out of the Partner-Down State

Note: you must not bring a failed peer back up unless the running peer is still functioning and ready to communicate with the failed peer. If you do otherwise, the restored peer will assume that nothing was wrong, and begin serving addresses normally. The restored peer must be able to communicate with the running peer right away so that it can discover that the other peer is operating in the partner-down state, and synchronize its database correctly.

After a prolonged outage where the running server has been placed in the partner-down state, when you are ready to bring a failed peer back online you simply need to confirm that the two servers can communicate with each other.

Start the failed peer up normally. It should restore communication with the running peer, discover that the running peer took over service, and synchronize its database with the running peer. Once the two machines have synchronized, the restored machine will wait for MCLT before serving clients. This gives any clients that received a lease from the failed peer time to expire, preventing conflicts.

At this point, both servers should return to their normal state, and begin serving clients in failover mode again.

Recovering from a Lost Lease Database

If a peer fails catastrophically and loses its lease database, you do not need to take any special action to recover. When the failed peer is repaired and able to communicate with the running peer, you may start it normally.

The failed peer will note that it has no state information, and assume that it needs to synchronize its state. It will download a copy of the lease database from the running peer, wait MCLT to prevent address conflicts, and then begin serving requests again normally.

Источник