Hi,
I've added a new (faster) Interface on the core, and I want to change the internal one. It used to be eth0, but now it's eth2. How can I change that on the web page? Even better, how can I have both networks configured as internal networks?
Say something like this: eth0 - 192.168.80.x; eth2: 192.168.81.x - both should be served as the internal ones. Any advice?
Isn't that what the Adminsite Home -> Advanced -> Network Settings "Swap Interfaces" button does?
FWIW, the underlying OS configs to select which HW ethernet interface (ie. which card/port) is mapped to which logical interface (ie. eth[0,1]), you have to edit /etc/udev/rules.d/70-persistent-net.rules (or maybe its generator rules in /etc/udev/rules.d/75-persistent-net-generator.rules ), and /etc/network/interfaces .
I don't want to swap interfaces - I want to add another internal interface, and here the admin site doesn't seem to help.
But the udev rules is a good starting point. Except that LMCE doesn't seem to use them for Interface names. Looking around, it seems LMCE still uses /etc/iftab for this. Is this going to change in 710?
The clues you need are in the web admin panel under advanced-configuration-devices-core. There is a field that specifies the ethernet interfaces. however what you are trying to do is bond several to the same network. Thats uncharted territory for LMCE. There probably is good Linux info for that and please let us know if you are successful.
Quote from: dukat on January 12, 2008, 03:37:57 PM
I don't want to swap interfaces - I want to add another internal interface, and here the admin site doesn't seem to help.
I don't know. I've no idea what that adminsite page would show with 3 HW interfaces.
Quote from: dukat on January 12, 2008, 03:37:57 PM
But the udev rules is a good starting point. Except that LMCE doesn't seem to use them for Interface names. Looking around, it seems LMCE still uses /etc/iftab for this. Is this going to change in 710?
I switched my own interfaces by editing that 70/network udev rules file to swap the eth0/1 names, and the admin site GUI kept synced to that properly.
So, I spent my Sunday playing around, and I made some progress. First, switching the interfaces was really easy - I just renamed the new eth2 to old eth0 in /etc/iftab and LMCE had no problems with the new interface. I'm still surprised about the other comment about udev rules for changing interface names. While know this working perfectly on my other client box running plain Kubuntu 7.10, my LMCE core only uses iftab.
Now, how to get the other interface as a second internal network? I configured eth2 manually in /etc/network/interfaces to to become 192.168.81.1. It took me quite a lot of time to figure out that I also had to update the firewall to make it usable. The following helped:
iptables -A INPUT -s 192.168.81.0/24 -j ACCEPT
With that, the connection was up, but I can use it only if I configure the client's IP manually. I don't know how to get DHCP working. I added a new section in /etc/dhcp3/dhcpd.conf on core
subnet 192.168.81.0 netmask 255.255.255.0 {
range 192.168.81.10 192.168.81.40;
}
But this didn't do the trick. Anyone knows about DHCP to give me a hint?
Quote from: dukat on January 13, 2008, 07:35:43 PM
So, I spent my Sunday playing around, and I made some progress. First, switching the interfaces was really easy - I just renamed the new eth2 to old eth0 in /etc/iftab and LMCE had no problems with the new interface. I'm still surprised about the other comment about udev rules for changing interface names. While know this working perfectly on my other client box running plain Kubuntu 7.10, my LMCE core only uses iftab.
Now, how to get the other interface as a second internal network? I configured eth2 manually in /etc/network/interfaces to to become 192.168.81.1. It took me quite a lot of time to figure out that I also had to update the firewall to make it usable. The following helped:
iptables -A INPUT -s 192.168.81.0/24 -j ACCEPT
With that, the connection was up, but I can use it only if I configure the client's IP manually. I don't know how to get DHCP working. I added a new section in /etc/dhcp3/dhcpd.conf on core
subnet 192.168.81.0 netmask 255.255.255.0 {
range 192.168.81.10 192.168.81.40;
}
But this didn't do the trick. Anyone knows about DHCP to give me a hint?
If your DHCPd is serving all the ethernet interfaces on its machine, then I think that should have worked. LMCE's dhcpd3 should default to watching each ethernet interface, so it should have worked. But maybe your method of installing/configuring the new interface is not revealing it to dhcpd3. Do the instructions at "dhcp server on multiple interfaces. (http://lists.freebsd.org/pipermail/freebsd-questions/2005-November/104507.html)" help? When you manually run a DHCP client on a host attached by a LAN segment to the new ethernet port on the LMCE Core (eg. (dhclient eth0) or whichever is the client's ethernet interface name), what does the client report?
If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.
Quote from: 1audio on January 14, 2008, 07:07:02 PM
If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.
The new ethernet is just another interface on the Core. The dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.
Quote from: 1audio on January 14, 2008, 07:07:02 PM
If the new interface is at 192.168.81.1 and the DHCP is serving on 192.168.80.XXX then its addresses won't work on the new segment or will they? I thought the new port would be in the same segment and just increasing the thoughput. This is a little different.
How could I bring it into the same segment? That would be also ok for me, and I think would make configuration much easier. I assigned a new network, because this is the only way I thought it would work.
I'll try the other DHCP hints later on. Thanks for the hints.
QuoteThe dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.
I don't thinbk its quite that simple. Networking is still very murky to me but I have picked up a few of the concepts. First it should only serve DHCP addrsses on designated ports or it will send them out the external port which would mess things up a little. Second if the IP rage is not within the range it can talk to (the class 1 class 2 etc. thing I have a fuzzy concept of) it may pass IP addresses out a port that can't talk back to the port.
I thought the second NIC on the network would be 192.168.80.XXX in an address not within the range that the DHCP serves. I'm doing this with an old GPIB network interface that needs a different prototcol (RARP) to get an IP address. I left a gap in the sequence and set up RARP in LMCE to supply that address (If I had a Windows network I'd be sunk.).
I'm not sure of the reason for a second NIC. That would help us understand the goal of this effort.
Quote from: 1audio on January 18, 2008, 07:33:36 AM
QuoteThe dhcpd should serve that interface as designated by the dhcpd.conf , which the one described in this topic seems (to me) to do, as it will start up and serve every ethernet interface found on the Core.
I don't thinbk its quite that simple. Networking is still very murky to me but I have picked up a few of the concepts. First it should only serve DHCP addrsses on designated ports or it will send them out the external port which would mess things up a little. Second if the IP rage is not within the range it can talk to (the class 1 class 2 etc. thing I have a fuzzy concept of) it may pass IP addresses out a port that can't talk back to the port.
I thought the second NIC on the network would be 192.168.80.XXX in an address not within the range that the DHCP serves. I'm doing this with an old GPIB network interface that needs a different prototcol (RARP) to get an IP address. I left a gap in the sequence and set up RARP in LMCE to supply that address (If I had a Windows network I'd be sunk.).
I'm not sure of the reason for a second NIC. That would help us understand the goal of this effort.
dhcpd defaults to serving every ethernet interface that's up when dhcpd is started, unless specific interfaces are specified on its startup commandline:
Quote from: (man dhcpd)
The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line. This should be done on systems where dhcpd is unable to identify non-broadcast interfaces, but should not be required on other systems. If no interface names are specified on the command line dhcpd will identify all network interfaces which are up, eliminating non-broadcast interfaces if possible, and listen for DHCP broadcasts on each interface.
LMCE's dhcpd is started by the /etc/init.d/dhcp3-server wrapper. Which includes /etc/default/dhcp3-server , which in turn defines the interfaces invoked by the init.d script in the dhcpd commandline. I expect that the LMCE Adminsite edits /etc/default/dhcp3-server .
That is the default, but with LMCE my understanding was that it should only be serving the internal network, not the external network. That is one of the points of having the networks partitioned, so that the LMCE network doesn't interfere with any existing network. And this is the way you are supposed to be able to have your external network served by your, say, broadband router's DHCP server, whilst LMCE serves the internal network.
1audio - you are right about this messing things up! And yes potentially you could end up with it passing out "non routable" addresses if it wasn't for the fact that for every interface that is listening you need to have a "scope" setup that responds to local broadcasts and has an IP range for a subnet that the LMCE interface itself resides on. That ensures that the "external" client can always talk at least to that interface - ie no need for routing which is essentially what you concern was about. Otherwise it could end up on an islanded subnet with no accessibility to a local router that could get its packets off that island - because the correct router for that range is on the other side of the LMCE box, the internal interface. Each interface can also have any number of other scope definitions for remote subnets. Those remote clients can't broadcast to the DHCP server because these broadcast can't leave their own subnet. But the router for that subnet can see these broadcasts, and can have an IP Helper setup to tell it where the DHCP server is. It then unicasts the request to the DHCP server with its own IP address as the source. The DHCP server then infers the subnet that the client is on from the router's source IP address, and if it has a scope definition for that subnet it will respond back via the router to the client with a lease.
BTW, there are ways of fudging it so that 2 nodes on different subnets can communicate without a router as long as they are physically and logically on the same network segment, but you don't want to go there!
Quote from: colinjones on January 21, 2008, 02:53:41 AM
That is the default, but with LMCE my understanding was that it should only be serving the internal network, not the external network. That is one of the points of having the networks partitioned, so that the LMCE network doesn't interfere with any existing network. And this is the way you are supposed to be able to have your external network served by your, say, broadband router's DHCP server, whilst LMCE serves the internal network.
Nah, like I said:
Quote from: Matthew on January 18, 2008, 04:00:06 PM
dhcpd defaults to serving every ethernet interface that's up when dhcpd is started, unless specific interfaces are specified on its startup commandline:
Quote from: (man dhcpd)
The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line. This should be done on systems where dhcpd is unable to identify non-broadcast interfaces, but should not be required on other systems. If no interface names are specified on the command line dhcpd will identify all network interfaces which are up, eliminating non-broadcast interfaces if possible, and listen for DHCP broadcasts on each interface.
LMCE's dhcpd is started by the /etc/init.d/dhcp3-server wrapper. Which includes /etc/default/dhcp3-server , which in turn defines the interfaces invoked by the init.d script in the dhcpd commandline. I expect that the LMCE Adminsite edits /etc/default/dhcp3-server .
# cat /etc/default/dhcp3-server
INTERFACES="eth1"
eth1 is my inside LAN segment. That file should say '
INTERFACES="eth1 eth2"' when eth1 and eth2 are the inside LAN segments (and presumably eth0 is the outside LAN segments). Then the trick is making /etc/dhcp3/dhcpd.conf specify the right PNP configs for the right subnets assigned on those eth[1,2] interfaces. I believe that the DHCPd will find different subnet {} blocks in the same dhcpd.conf file, and assign each subnet {} block to an ethernet interface in the order specified on the dhcpd commandline (and therefore in the order in the INTERFACES environment var defined in /etc/default/dhcp3-server ). So each subnet {} block can be defined with IP# ranges, PNP and other parameters specific to its ethernet interface.
Thank you all for the hints you gave. In the end this proved way to complicated for me so I dropped it...
Still I think having two internal interfaces would make sense, especially if one is a wlan device acting as an access point. Well, I might try it again if I can configure this from the web in LMCE 8.10. :)
dukat:
I understand how hopeless this seems to the uninitiated. I'm a little lost here as well. However I will figure out how to add a wireless NIC as an access point over the next few weeks. Once I have it working I'll bug the right people on how to get LMCE to set it up properly.
Mathew, Colin:
Thanks for the advise. I now know which files to screw up to get this working.
-1audio
Quote from: dukat on January 24, 2008, 05:28:19 PM
Thank you all for the hints you gave. In the end this proved way to complicated for me so I dropped it...
Still I think having two internal interfaces would make sense, especially if one is a wlan device acting as an access point. Well, I might try it again if I can configure this from the web in LMCE 8.10. :)
Changing "eth0" to "eth0 eth1" in /etc/default/dhcp3-server , and adding a second 6-line subnet block in /etc/dhcp3/dhcpd.conf is too complicated? I wish someone would try it out and report back the test results, so I could find out whether my research into this solution actually works for that use case.
Serving a lot of simultaneous but different video streams to different rooms could need multiple inside LAN segments. Or avoiding QoS configs by dedicating a separate inside LAN segment to telephony (or home automation, or alarm video, etc). I'd like to see whether LMCE handles those configs by DHCP, which is LMCE's plug & play model, or whether something new needs to be added to the SW. Or just a GUI for adding the other segments and their respective configs.
Easiest way to get a wireless accesspoint added is to just hook up a wifi router to the switch on lmce's internal network. Just need to turn off it's dhcp and leave the WAN port unused.
Quote from: Matthew on January 24, 2008, 05:50:14 PM
...
I wish someone would try it out and report back the test results, so I could find out whether my research into this solution actually works for that use case.
...
Why don't you get off your lazy ass and try something yourself for a change? Instead of your usual: adding a lot of noise and then waiting for everyone to hand you everything on a silver platter so you can claim you've "solved" something, it is getting pretty annoying.
Quote from: Zaerc on January 24, 2008, 06:02:59 PM
Easiest way to get a wireless accesspoint added is to just hook up a wifi router to the switch on lmce's internal network. Just need to turn off it's dhcp and leave the WAN port unused.
Quote from: Matthew on January 24, 2008, 05:50:14 PM
...
I wish someone would try it out and report back the test results, so I could find out whether my research into this solution actually works for that use case.
...
Why don't you get off your lazy ass and try something yourself for a change? Instead of your usual: adding a lot of noise and then waiting for everyone to hand you everything on a silver platter so you can claim you've "solved" something, it is getting pretty annoying.
I put together a solution for this specific problem which doesn't require very much of the requestor to try out, instead of giving up. Their testing the results would be good for the whole community.
That's what working together as a community is like. I'm working on quite a lot of actual functions in LMCE right now. I've been asking for some help navigating code and not getting it, but that's not stopping me, though it's slowing me down. There is absolutely no reason for you to talk like such an asshole, except you've got some kind of grudge against me for acting like an adult when you don't. As I've asked before, get off my back already and either contribute something constructive or shut up.
Oi you two, off the soap boxes please! Zaerc has contributed plenty, esp helping people on these boards. And Zaerc - where's the chill pills gone? You've been very mellow for the last few months ;)
I reckon it would take about 10 minutes max to chuck in an extra nic into a machine. But I guess that's to much effort to do yourself to test your own "research". :P
As far as constructive goes, read my post again it has the solution to adding a wireless acesspoint. So why don't you take your own advice and "contribute something constructive or shut up" yourself instead of relying on others to hand you everything on a silver platter.