[Keep the LMCE network in the 192.168.80.0 range!!]

Back to your issue m3.  Did you turn off the firewall on the core.  You can sit there and open up ports and create routes but since you have a firewall between you and the Internet I would disable the firewall on the core all together. 

I didn't actually disable the firewall from the web interface. I was using iptables directly (i.e. iptables -L), saw no rules active, and so assumed the firewall was off.  I've now disabled both IPv4 and IPv6 firewalls.

Also, I'm not sure I understand this log you posted.  Is 192.168.80.4 the IP address of your PC?

 

The 192.168.80.4 IP is the IP that LinuxMCE keeps assigning to the Generic Web Orbiter.  The Proxy Orbiter gets the IP 192.168.80.3.  I didn't input these - they get added automatically by LinuxMCE.

Here's the deal, make your life easy and assign a different IP range to the external network.  Keep the LMCE network in the 192.168.80.0 range!! So IPcop will provide addresses in the 192.168.25.0 range (external).  That could possible give your core an external ip address similar to 192.168.25.3, and your PC an IP address like 192.168.25.2.  To access the web orbiter from the PC type 192.168.25.3 in the address bar. 

[/quote]

Yep, I've already done this.  My IPCop firewall is handing out DHCP IPs in a different range.  My core has two NICs: it is getting its external IP from IPCop's DHCP sever.  The LinuxMCE network is in the default range of 192.168.80.0/24.  LinuxMCE is running its own DHCP sever here.

Hmm...I just realized my external PC network doesn't have a route to the internal LinuxMCE network.  I should add the route on my IPCop system.

Can you ping the core from the external network?  It sounds like you turned on remote access to the core on port 80 , which explains why you can get to web admin but not the orbiter or ssh.  Click on the firewall option under networking and disable IPV4 and 6 firewalls. 

Yes, I can ping the core.  The firewall is disabled now.

I'm also seeing these messages in the web orbiter log:

03-08-2011 13:43:26
Attempting to create socket on host 192.168.80.4 port 3461 ... OK.
socket_connect() failed.
Reason: (113) No route to host
Closing socket ... OK.

I didn't enter the IP when I created the Generic Web Orbiters, so it's being added automatically. What I don't understand is why.

Can I use the core's IP? 

I would be interested in knowing which page it is, as maybe I have got this wrong. I would say it's OK for testing purposes, but seeing as you have got it things up and running now (mostly), then why not use your core as your gateway.

Because IPCop gives me a level of control over my network that LinuxMCE does not.  For example, I can have three separate internal networks.  I can put the wireless network in a different range, and prevent any wireless clients from accessing the wired network. Yes....I'm  being very cautious about my home network.

But surely in your setup LMCE won't be providing the IPs to PC1 and PC2? Which is where you are trying to use the web orbiter from! I don't know, I'm no expert. I would try it on the LMCE internal network as I said, if only temporarily.

Hmmm...maybe my understanding of the web orbiter is wrong then.  Does the web orbiter have to be on the internal network?  I thought it could be any device running a web browser.

I'm sure there are people that are using that kind of network setup successfully, but I wouldn't go so far as to say that it is "recommended" - where did you get that information from? As far as I know, LMCE should always be the gateway/firewall to the Internet, and your LMCE devices should be on the internal network. Your network setup might be the cause of many of your problems.

What?! It's in the wiki!! I'll have to find the page that mentions it.

In any case, what I'm doing should not in anyway affect the operation of LinuxMCE.  My current network may as well be the Internet - the Core won't know any different.

Check to see if you have a folder called "bits" in the directory "/usr/pluto/orbiter". If you don't, make one.

And don't forget to Full regen your orbiters before you reload.

The dir is there, but it's empty.

I've always done a "full regen" followed by a quick reload of the core when working on the web orbiter definition.  But, I'm still not seeing any icons to click/touch/angrily wave my finger at.

Not quite sure what you mean by "one of my PCs on the external network"; I'll assume you mean the internal network.

My LinuxMCE network is separate from my PCs.  I'm not using my core as my gateway/firewall to the Internet: that job stays with my IPCop firewall.  This is what my network looks like:

internet ---- ipcop ----- switch ----- PC 1  (web orbiter)
                       |                 |
                       |               PC 2
                       |
                    Core
                   /   |   \
                 /     |     \
             MD   MD  Other LinuxMCE stuff
 
So, as far as LinuxMCE is concerned, my PCs are external.  Make sense?  I'm pretty sure I have a typical config, or at the very least, one that is recommended.

Check to see if you have a folder called "bits" in the directory "/usr/pluto/orbiter". If you don't, make one.

And don't forget to Full regen your orbiters before you reload.

Ok, I'll check.  I can't ssh to my core anymore, though I can bring up the wed admin page just fine.  I don't know why I randomly lose ssh access.  LinuxMCE is pretty much the most temperamental Linux distro I've ever used.

I followed the Wiki's step-by-step directions for building a Web Orbiter.  After the build was done, I did a quick reload of the core.  I browsed to the web oribiter from one of my PCs on the external network, and was presented with a mostly empty screen.  The only items on it were:

- text saying WebOrbiter Screen
- 5 buttons that said: Home Back Refresh Exit Logout (in that order)

I don't what I've done wrong.  I don't see anything obvious in the logs.  I'm not sure how to trouble shoot this.

What should I look at first?

I was able to get my MD booted after I installed the newest snapshot of 0810.  I still had to run startup-script.sh, but the MD booted and kicked off the diskless image build - nice!

NOTE: I've actually managed to get my MD to boot and the diskless image to be created.  However, I want to reply to the questions in this thread before leaving it and starting a new one (I have new problems....whooooopeeee!).

Are you able to have other devices on your internal network receive (192.168.80.0/24) DHCP addresses and connect to the core? If yes, then your cores NIC seems to work okay.

Couldn't before installing the r8168 driver.  Now I can.

If you can connect to the core, check if dcerouter is running on the core,

Code:

ps ax|grep DCERouter.log|grep -v grep

Not running.  I assume I can manually start it - I will research.

and have a look in /home/coredump/1 dir if there are any coredumps in there.

I have three core dumps from a few days ago.  Should I inspect them?

Downloaded and installed the latest snapshot.  This is what I did:

1. Ran install
2. Appeared to complete successfully, so rebooted.
3. Logged into Kubuntu desktop
4. Tried to stop network services.  Got an error about an unknown device, even though both NICs were up.  eth0 had 192.168.80.1 IP, and eth1 had IP from my external DHCP server.
5. I unloaded the eth0 module, r8169.
6. Installed r8168 module.  After install script finished, eth0 was back up with old IP.
7. I added the r8168 module to /etc/initramfs-tools-interactor/modules
8. Created the default diskless image
9. Ran the final install script by double clicking the icon on the desktop
10. Rebooted after the install finished.
11. Last step of install ran and completed after reboot
12. Powered up the Jetway Ecomini MD
13. After it got an IP, it began the PXE boot.
14. After eth0 apparently came up, the Jetway reported it couldn't connect to the router, so it rebooted.
15.  60 minutes later, it's still rebooting because it can't find the router.

WTF.

FAIL!  Reinstall of LinuxMCE and install of r8168 module right from the get go did not fix anything:

1. MD PXE boot dies after saying it can't contact the router.  The ONLY way to get past this step is to run "startup_script.sh" after EVERY SINGLE CORE REBOOT.
2. The MD's diskless image never runs.  The MD might say it's announced itself to the router, but the core doesn't actually do anything.

There is some seriously broken shit in the LinuxMCE snapshot I'm using.

Run this on your core...

Code:

modprobe r8168
depmod -a
/usr/pluto/bin/Diskless_BuildDefaultImage.sh

The first two steps get were done by the install script for the r8168 module.  I ran the script in the final step, rebooted - no change.  The MD just at the same screen, and there was no diskless image being created on the core.

I'm going to reinstall LinuxMCE.  Before I run the final install script from the desktop, I'm going to install the r8168 module.  If things still don't work, I'll try a new DVD snapshot.  If shit still fails, I'll dance on the computer.

Assuming you did a lot of cocking around before you found the solution to your core's NIC problems, reinstalling might be an idea, just to eliminate the possibility of a messed up setting somewhere.

Nah, did nothing of the sort.  Actually, the install I'm working with right now is new.

What steps did you take exactly for the unrecognised NIC on your MD?

I did what was in those links.  I'd already installed the r8168 driver, so I did the other stuff:

- included the r8168 module in /etc/initramfs-tools-interactor/modules
- recreated the diskless image (the way it's described on the 0810 install page)
- I don't have a /usr/pluto/diskless dir, so I searched around until I found the post about running "startup_script.sh" to get past the MD boot error.

So that's where I am.

BTW, how can I tell if the diskless image is actually being created?  I looked on the core and can't find any running process that would indicate the MD's image is being created.

One other thing: although I can't ping or ssh to my core from the external network, I can definitely ping the external network from the core.  I didn't look at the iptables rules - maybe they're messed up?

m3freak,

please remember rule #1 - MD creation can take longer than 45minutes.

Ok, fair enough.  But, why do I have to run the startup_script.sh script every time I reboot the core? Well, that's been the case for the Jetway Ecomini MD, anywyay.

Also, when I do run the startup_script.sh script, the external interface of the core stops responding.

So, I looked at the stuff tkmedia linked to and now I have a MD that no longer kernel panics, but instead dies a bit later in the boot. The error message printed is:

"Error: cannot connect to router: rebooting in 5 seconds."

The MD then reboots, and the same thing (as above) happens again.

I searched the forums and came across this thread:

http://forum.linuxmce.org/index.php?topic=8959.0

I tried out what Murcel suggested, and it did indeed get the boot even further along.  The problem now appears to be the MD pausing indefinitely after printing out something about "we've announced ourselves to the router" - I can't remember the exact error.  I let the MD sit like that for 45 minutes and saw no change. So, I rebooted the core for shits and giggles, and powered the MD back up after the core reboot was complete.  Unfortunately, the original error (Error: cannot connect to router: rebooting in 5 seconds.) came back.

I'm assuming I can get past this error if I run the startup-script.sh script again.

Questions:

1. Why do I have to keep running the startup-script.sh script?
2. I don't see any "diskless" script running on the core when the MD gets to the "announced ourselves to the router" message.  How do I fix this?
3. Why is my install so broken? Did one bad NIC driver really introduce this many problems?