With ifconfig
on OS X you can find netmask :
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
netmask 0xffffff00 means 255.255.255.0
And for finding gateway address use arp -a
or as geekosaur said use netstat -nr | grep '^default'
.
As @bmike said, Internet Sharing hides a lot of complexity behind a very simple interface, and some of your questions can't be answered authoritatively without interviewing some of the Apple engineers behind it. But that won't stop me from taking a stab at it...
1) AirPort is different from the other interface types because in order to share over AirPort, your Mac has to actually create the wireless network (as opposed to just providing service over an existing ethernet, FireWire, etc connection). This means that InternetSharing needs to have a bunch of info about how to create the wireless network: network name (SSID), channel, security, etc.
2) Resharing over the same ethernet interface is useful under some circumstances. For example, on my home network my ISP provides limited number of static IP addresses for my use. I run a Mac doing the equivalent of Internet Sharing (actually, I set up the daemons manually as @Spiff recommended) to reshare over the same ethernet. Result: if I put a computer on my home ethernet and config it via DHCP, I get a private (behind-the-firewall) IP address from my virtually unlimited internal pool. If I manually config the computer with one of the public IPs, I get full unfitered internet access, but use up one of my limited public IP pool. Because they're both on the same network, "moving" a computer behind or in front of the firewall is just a simple configuration switch.
On the other hand, if you did this same trick on an ethernet network that already had a DHCP server, computers attaching to the network would randomly get configuration from one server or the other, leading to unpredictability, confusion, and hair-pulling. It's definitely a use-only-if-you-know-what-you're-doing feature. Fortunately, Internet Sharing is smart: if it detects another DHCP server on "its" private network, it shuts itself off to avoid trouble.
3) I don't know of a way to change the private IP range on an IS-created wireless network. On the other hand, it shouldn't really matter, since the network is being created by Internet Sharing, and therefore it doesn't have to worry about conflicts with any existing network numbering.
4) You can add interfaces with Apple's USB Ethernet Adapter. Get some USB hubs, and pile them on!
Best Answer
Your Macbook is bridging 2 different networks.
The first, from your router, would presumably be 192.168.1.0
That would make the router itself 192.168.1.1 & it will then hand out DHCP addresses from 192.168.1.2 up to as high as .254
In order to prevent potential IP Address conflicts. Apple's Internet Sharing will use an address of one order higher for each Ethernet connection you ask it to use [with Thunderbolt or USB adapters, this could be many, on rare occasions] so the first one will be 192.168.2.x, the one after 192.168.3.x etc
The only thing that puzzles me slightly is that the reported self-assigned address is 169.254.x.x. This is a private, self-assigned address that an interface will use if it cannot find a DHCP server to assign it one.
For a bridged connection, though, I would have expected it to assign itself 192.168.2.1, as the gateway for your bridge & not be trying to pick up a DHCP address at all, as it is the 'router & gateway' to your new node.
The fact that your second machine can connect successfully with an assigned address of 192.168.2.2 & a gateway of 192.168.2.1 would tell me that the self-assigned address might be misreported somewhere along the line; as otherwise it oughtn't to be able to connect.
After some extensive Googling I discovered this, which may explain the apparent discrepancy.
TL:DR
Don't set DHCP on your shared connection in the Macbook, because it is supposed to be the 'master'. Allow the OS to set it up itself, which it will do correctly, with a fixed IP of 192.168.2.1 for itself & 192.168.2.2 ..3 ..4 etc for devices using it as a bridge