Internet connection...

[Frank]

Dear Massimo,

you'd sent "us" some instructions to upgrade QLC+ Network.

Question:
Is this upgrade related to the "problem" that the original image for the Raspi doesn't connect to the internet (... as I reported a few days before inside the "wrong" topic, USBmount issue)?

As I described there, an internet connection wasn't possible until a manual reconfiguration of the network parameters inside the /etc/network/interfaces file...
My Raspi was running fine after this adaptation of the interfaces file...

When I applied the steps you reffered to then the upgrade had finished, but after a reboot the Raspi didn't respond via WLAN (WinSCP, PuTTY, web interface) at all!

So I had to copy the original image file you delivered (2015-06-27) onto the sd card again and to do all the initial process to get it working (... TFT configuration of cause too...). This isn't a problem for me...

But after doing so, the internet connection was lost again, and so I couldn't apply your Network upgrade, so the process you preferred isn't practicably...

Should this upgrade solve the problem I described above or is it thought for any other subject?

Until now, I couldn't find any hint concerning this upgrade package, even after searching inside the forum and/or the web page you are managing.

I would be glad to get further advice.

Thank you very much in advance

Frank

[mcallegari]

Frank,
you keep asking questions about the internet connection without saying:
1- WiFi or ethernet
2- if ethernet, does it work ?
3- if WiFi, which adapter are you using ?
4- if the configuring via web interface works or not
5- what is the output of 'ifconfig' ?
6- what is the content of /etc/network/interfaces
7- static or dynamic IP address ?

Please give the right information otherwise I can't help.

[Frank]

Hi Massimo,

thank you for observing this topic so fast...

To avoid looking into that other topic I mentioned before (USBmount issue), I'll repeat most of the facts here:

1. usually I'm using WiFi, but during first configuration I have to use the ethernet connection

2. via ethernet there is no internet connection

3. the USB WLAN dongle (I am using) connects to the WLAN network very well! That means, that the access from a PC to the Raspi works fine (WinSCP, PuTTY, web interface via Chrome browser). So this shouldn't be a driver problem, should it? The Raspi is seen by the router!

4. the final configuration of the Network is realized always via web interface! During the first start (when a new image is transferred), there is a network cable connected between PC and Raspi. The PC is configured to have the IP address 192.168.0.100, so it finds the Raspi as http://192.168.0.252:9999. During this session the wlan0 of the Raspi will be configured to get a static IP address, correct SSID, valid Password, Netmask and Gateway. After a reboot, the Raspi can be accessed via WLAN (WinSCP, PuTTY, web interface via Chrome browser) and works fine, so far... But no internet access, as explained.

5. after that Network configuration, the command 'ifconfig' delivers:

Code: Select all

root@raspberry-pi:~# ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:92:14:66
          inet addr:192.168.0.252  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:fe92:1466/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10119 (9.8 KiB)  TX bytes:57974 (56.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4036 (3.9 KiB)  TX bytes:4036 (3.9 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:13:ef:10:1d:e3
          inet addr:192.168.178.36  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: 2003:4a:ce04:c800:213:efff:fe10:1de3/64 Scope:Global
          inet6 addr: fe80::213:efff:fe10:1de3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:136 errors:0 dropped:8 overruns:0 frame:0
          TX packets:79 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21316 (20.8 KiB)  TX bytes:21352 (20.8 KiB)

6. the content of /etc/network/interfaces file reads as:

Code: Select all

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
  address 192.168.0.252
  netmask 255.255.255.0
  gateway 192.168.0.1
auto wlan0
iface wlan0 inet static
  address 192.168.178.36
  netmask 255.255.255.0
  gateway 192.168.178.1
  wpa-ssid HBL11-16
  wpa-psk 9543xxxxxxxxxxxx

7. as mentioned above, a static IP address is chosen

Then, if I start for example the command 'ping http://www.google.com' (via PuTTY) it results in:

Code: Select all

root@raspberry-pi:~# ping www.google.com
ping: unknown host www.google.com

And then, if I copy the following lines into that interfaces file "by hand":

Code: Select all

auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "HBL11-16"
wpa-psk "9543xxxxxxxxxxxx"

and reboot the Raspi, everything runs fine:

Code: Select all

root@raspberry-pi:~# ping www.google.com
PING www.google.com (216.58.213.4) 56(84) bytes of data.
64 bytes from ber01s14-in-f4.1e100.net (216.58.213.4): icmp_req=1 ttl=56 time=44.0 ms
64 bytes from ber01s14-in-f4.1e100.net (216.58.213.4): icmp_req=2 ttl=56 time=35.4 MS
.
.
.

Now the command 'ifconfig' delivers:

Code: Select all

root@raspberry-pi:~# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:100 (100.0 B)  TX bytes:100 (100.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:13:ef:10:1d:e3
          inet addr:192.168.178.36  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: 2003:4a:ce04:c800:213:efff:fe10:1de3/64 Scope:Global
          inet6 addr: fe80::213:efff:fe10:1de3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:455 errors:0 dropped:20 overruns:0 frame:0
          TX packets:242 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:73679 (71.9 KiB)  TX bytes:60412 (58.9 KiB

If you need some additional information, or if I'd forgotten some useful details, please let me know.

Many thanks in advance
Frank

[mcallegari]

OK Frank, now I have all the information necessary to understand what's going on !

And the winner is...the DNS !
In a home network, a router is normally in charge to deliver IP addresses but also DNS addresses to the DHCP clients.
So basically your RPi with dynamic IP (DHCP) works because the DHCP client sets also the DNS address provided by your router as well.

You can check what's written in the file /etc/resolv.conf
You should see something like
nameserver x.x.x.x

When using a static IP address, instead, the RPi is not necessarily in the need of reaching the internet.
To do so, you need to manually modify the /etc/resolv.conf file and add a nameserver entry.

For example "nameserver 8.8.8.8" will use a Google DNS to resolve the internet hostnames.
Please try that and let me know if it works.

In any case this is generic knowledge of how a Linux system works. Google could have solved this issue for you.
It is true that QLC+ could write the resolv.conf file when setting a static IP, but as I said, it might we an unwanted behaviour.

[Frank]

Hi Massimo,

I tested your suggestion (adding 'nameserver 8.8.8.8'), but without any success so far...

Therefore I started from scratch again and did some testing of the original state, using the ethernet cable:
I'm able to connect the Raspi via Web interface, WinSCP, PuTTY (and so on) from my Windows PC.

Without any changes, the /etc/resolv.conf file consists of:

Code: Select all

nameserver 8.8.8.8
nameserver 208.67.222.222
nameserver 208.67.220.220

But when I try to connect to the internet ('ping http://www.google.com') there is no Google found...

Next change via Web interface to the Raspi, "Network configuration", input of the SSID and WPA-PSK Password (this time the "radio button" remains at "Dynamic (DHCP)" !!!) , then "Apply changes" and "Reboot"

Now /etc/resolv.conf file consists of (automatically changed by the system):

Code: Select all

domain fritz.box
search fritz.box
nameserver 192.168.178.1

where 'fritz.box' is the name of my router and '192.168.178.1' is its IP address.

The contend of /etc/network/interfaces is now:

Code: Select all

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
  address 192.168.0.252
  netmask 255.255.255.0
  gateway 192.168.0.1
auto wlan0
iface wlan0 inet dhcp
  wpa-ssid HBL11-16
  wpa-psk 9543xxxxxxxxxxxx

but again no internet connection.

The only way to get the access is to change that /etc/network/interfaces file (by hand) as described in my previous report (above).

I tried the whole configuration (from scratch) several times to avoid any mistake... Do you think that I'm configuring anything in a wrong way? Should I test other suggestions of you?

Thank you in advance
Frank

[Frank]

Hi Massimo,

another observation of the behaviour concerning that "firstly not working internet connection" is the following:

If the Raspi is configured via Web interface (page "Network configuration") for WLAN the item "Dynamic (DHCP)" is selected and 'SSID' as well as 'Password' are entered, then 'Apply changes' and final 'Reboot' is forced, the internet connection won't work (... as I described several times)...

... but, if afterwards the command

Code: Select all

service networking restart

is entered (via PuTTY for example), then the Raspi will be connected to internet immediately!!!
This connection is working until the next restart of the Raspi. After a restart it won't work again, but this command does it trigger again, and so on...

Maybe this could be another hint respective the cause of this behaviour...?

At the moment, I think it's the best way to configure the /etc/network/interfaces file by hand (via PuTTY) to get full and permanent access to the internet. The content of this file should be:

Code: Select all

auto lo
iface lo inet loopback
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
  wpa-ap-scan 1
  wpa-scan-ssid 1
  wpa-ssid "HBL11-16"             <-- your SSID here, between the quotation marks
  wpa-psk "9543************"      <-- your WiFi password here, between the quotation marks

BTW, if the Raspi is configured as mentioned above (via Web interface, WLAN item "Dynamic (DHCP)", 'SSID', 'Password', then 'Apply changes' and final 'Reboot') the fields for 'SSID' and 'Password' are always empty (although filled before), maybe a "bug" of this page...

Frank

[pengumaniac]

Dear Frank,
I think its a question about subnetting & routing.
I don't really understand why you want to keep your Lan in subnet 0, while your Wlan is in subnet 178 of the 192.168.-net

as you told in previous post

Code: Select all

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
  address 192.168.0.252
  netmask 255.255.255.0
  gateway 192.168.0.1

if noone told you: gateway=router, I don't know exactly if the following wlan -dhcp isn't ignoring this and tries to route through a gateway that doesn't exist

so try gateway 192.168.178.1 with that setting and do
service networking restart
then ping (by ip doesn't need nameservers) at first fritz.box, then others

if that doesnt work
Plan B: take Lan on PC and RPi into subnet 178, too (but not with the same Ip on lan & wlan!) or simply connect all per dhcp to your fritz.box....

[Frank]

Dear pengumaniac,

thank you for discussing my questions.

Please let me give another "historical" overview of this theme...

Until now, let's say for about the last half year, it wasn't interesting for me to get any internet connection from the Raspi that is used as QLC+ controller...

Massimo "always" delivered a link to the complete image file when a new version was released. But now - July 7th - he sent us "only" a "Network upgrade" link, and so I needed such an internet connection...

On the other hand, for testing several touchscreen displays, Massimo gave some hints for using tools (see chapter 7.4. inside "Q Light Controller+ on the Raspberry Pi" user guide, July 3rd) that aren't on-board, so commands like "apt-get update" are necessarily...

These "news" were the cause for me to get an internet connection from a running Rpi QLC+...

When you start the Rpi QLC+ from scratch, the only possibility to get it embedded into your own network is to use its "standard" IP 192.168.0.252 via ethernet cable, as the original image is configured this way. This has to be done by a direct wiring (LAN cable) between a PC and the Rpi!

And this ethernet IP stays as a kind of "back door" if anything doesn't run as expected. Otherwise you have to connect a monitor (hdmi) and keyboard to the Rpi to gain access again, and then you can do necessary changes. This is a little bit "complex" if the Rpi isn't at your desk...

... and this is the reason for not changing these standard configuration (IP = 192.168.0.252) for the ethernet cofiguration...

And, if you are using the Web interface of the Rpi QLC+ (firstly via that ethernet link) and you want to establish a WLAN connection, you can choose between a static IP for this WLAN or a dynamic one. These are the only possibilities to get it connected, and you have to choose from these! But neither the first option nor the second one results in any success, referring to the wished internet connection, if needed. But it works fine, if you only have to access the Web interface of the Rpi QLC+ via WLAN, to "Load project", to change "Configuration" or use the "Simple Desk" and so on.

Therefore I was looking for an useful configuration and found (until now) only that one, I described above. And as you mentioned too, this is the way to connect both (lan & wlan) per dhcp to the router...

... but, if there is later the necessity to get the Rpi QLC+ connected via ethernet cable directly from your PC, the static IP is gone and no access is possible this way (monitor and keyboard will work, ethernet directly to the router should work). The workflow is changing and changing, and sometimes one don't know what to do next. So it would be a good idea, if "one" solution could meet "nearly every" requirement, if possible...

I'm yet hoping, that Massimo will implement some improvements, so that the original image file supports the internet connectivity by itself...

Nevertheless I'll do some further tests as you mentioned, but for me, the latest configuration (I described above) works so far! But other users should know how to get it working too, when internet connection is necessarily...

Thank you again
Frank

[mcallegari]

Frank, this discussion is getting ridicolous.
You don't seem to accept how I configured the RPi image because you don't understand the reasons behind it. Reasons already discussed in this forum by the way.

When you deal with a network device (a router, a wifi repeater, etc..) they have "factory default" settings so the manufacturer can write in the manual "when configuring the device for the first time, you can reach it at the IP address x.x.x.x"
They set the device with a static IP address, so you are sure you can reach it there. If they had a dynamic IP address, you wouldn't know which IP they get, so the whole first time process would be even harder.
That's exactly what I've done, like it or not, and it's all documented in a PDF that you have.

Now this is getting ridicolous, because you don't accept the fact that the first time you need to access the RPi on a static IP address, change it to whatever dynamic configuration you want and then do apt-get or QLC+ upgrades from the internet.
It takes 3 minutes if you know what you're doing.

I'm yet hoping, that Massimo will implement some improvements, so that the original image file supports the internet connectivity by itself...

You guys always believe that a software can read your minds, but it can't.
For example at home I use static IP addresses in my LAN, so a DHCP "factory configuration" wouldn't work for me.
Please be respectful for the choices I've made, because I know exactly what I've done, something that apparently you don't understand.
You are the only one who complains, over hundreds of RPi users.
Also, please stop saying "until Massimo improves this and that" because there's nothing to improve here. As I said before: if the QLC+ web interface produces faulty network configurations, I will fix it.
Otherwise, if you're still looking for a Linux teacher, then please use Google as these topics are immensely documented all over the internet.

[Frank]

Dear Massimo,

sorry if you are really disappointed, but I don't think that the questions and discussions concerning this topic are getting ridiculous...

Maybe that Linux experts don't need any support to get the Rpi QLC+ working related to internet connections, but I can't imagine that musicians and electronic enthusiasts can solve such problems by studying Linux and by reading newsgroup articles...

Your development - QLC+ adapted to the Rpi - is so wonderfully, because it enables standalone solutions in a wide range of lighting control! There is no other tool chain available, that allows using a standard PC for design of a light show and transfering the result onto that tiny Rpi. That is your merit!

I understood very well, that it is necessary to have a "factory default" setting concerning the IP address, and I would like to use this one for any "emergency", for example after upgrading to a new release (because the Rpi looses these adjustments afterwards...).

In my case, after the WLAN access is configured successfully, I won't use the ethernet connector later on, because the Rpi is too far away from the router. WLAN is very usefully to get access to the Web Interface of QLC+...

And as I followed your instructions before - while a static IP address was configured via Web interface, I added "nameserver 8.8.8.8" to the /etc/resolv.conf file - but this didn't work, I asked again. And as you mentioned I should try that and let you know (if it works), I did so... Even if there is a dynamic IP address configured (via the Web interface) an internet access wasn't possible. I described that above because I couldn't find additional information about that (... and because you asked me to tell you about the results).

So it would be very helpfully if you could test what goes wrong.

I for myself have to "overwrite" the contend of the often mentioned /etc/network/interfaces file with the new one (to get the desired internet connection)

Code: Select all

auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
  wpa-ap-scan 1
  wpa-scan-ssid 1
  wpa-ssid "HBL11-16"
  wpa-psk "9543************"

but the drawback is, that the Rpi QLC+ isn't reachable directly from the PC via ethernet cable (if anytime required). I would like to have this possibility, but I couldn't find a solution until now... Maybe that this "desired" configuration isn't possible at all, and so it would be very nice if you could state, that this isn't feasible (at the moment?).

Thank you in advance
Frank

[plugz]

Hi,

Can you add also the results of the command "ip route" or "route" ?

[pengumaniac]

Frank, maybe my last advice was a bit pertly, but the remaining covers the basics:
per default there is no communication between different subnets until you setup the right routes ....
forget about the test of nameserver 8.8.8.8. in resolv.conf, this was given as example and has an universal qualified sense,
but since you told us afterwards about your Fritzbox, your findings with that are already meaningless, do not need any further comments and doesn't help others at all.
So having

Code: Select all

domain fritz.box
search fritz.box
nameserver 192.168.178.1

should be just fine.
Your last post of /etc/network/interfaces convinces me that you've comprehended nothing at all:
eth0 (cable) to Router gives you an IP in his net;
eth0 to PC doesn't do anything as long there is no dhcp-server running on it

I didn't test that image till yet and right now my RPi is on an exhibition to present some videoloops, so I can't even simulate that special situation for my own interest.

I agree with Massimo, should he release an extra Image for Fritz or perhaps Vodafone etc. - only by the need to change that subnet number?
If you don't like to make Linux experiences, buy a Dlink Router, then you have net 192.168.0.0 per default.
I' m shure if that has been your precondition, you have had less problems.

Using Fritzbox too, I myself would mount the SD's /root partition via cardreader and edit that simple setting on PC, if that's necessary at all. But thats spoken hasty again and I suspect, as you're talking about putty that you haven't another Linux running....
I believe nearly, your ventures are a bit oversized, as well. With Linux you have to show much more self-initiative and flexibility, and RPi can be extreme-linuxing in so many cases all the more.
Don't believe you get all masticated because you've donated once some few cents.

By shure you can change the net in your Fritzbox, too
but be aware this might be a little bit dangerous without knowlegde what you're doing.
So don't forget to backup the box at first, then look at Heimnetz > Netzwerk, 2.Tab Netzwerkeinstellungen, half page down Button IPv4 Adressen ...
Now excuse me, the fan gets quiet on my good old gobook, seems kernel 4.1.2-gentoo is now ready to give him a try - there is some fancywork to do before I 'm save to do the reboot

cu on the other side!

PS: also have a look on the 1.Tab "Geräte und Benutzer" at the entries, perhaps you have to do clean up sometimes.
As I was working once with openelec instead of raspbian, there was an competing entry in that list and RPi couldn't connect, too.

[Frank]

Hi plugz,

thank you for your time!

I tried the commands you'd suggested and you will see the results below. Firstly I have to remark, that the results depend on the actual "Network configuration" of the RPi QLC+, that was actually carried out via Web interface.

I left the "eth0" parameters at "factory defaults", that means "Static", "IP Address: 192.168.0.252", "Netmask: 255.255.255.0" and "Gateway: 192.168.0.1". These values are usefully for me, as my RPi QLC+ is normally connected via WLAN to the "home network" (for loading project files and so on), while the ethernet cable is only used as a point-to-point connection, direct to my PC in case of "emergency", if the WLAN doesn't connect anymore, for example after a "Network upgrade" delivered by Massimo. If such an upgrade is finalized, the previous WLAN configuration is lost. I think this is normal, isn't it?

I configured Wlan0 (via Web interface) as "Dynamic (DHCP)" and therefore only the "SSID" and the "WPA-PSK Password" were required.

After restart ("Reboot") and removing the ethernet cable, the RPi QLC+ is accessible, and can be controlled via WLAN (Web interface) from any PC (inside the "home network") as well as from a smartphone... WLAN works perfectly so far...

"Your" commands provide the following results:

Code: Select all

root@raspberry-pi:~# ip route
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.252
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.36
root@raspberry-pi:~#

and

Code: Select all

root@raspberry-pi:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.178.0   *               255.255.255.0   U     0      0        0 wlan0
root@raspberry-pi:~#

But if I try "ping http://www.google.com" in this situation, "Destination Host Unreachable" is the answer of the RPi...

If I input the command "service networking restart" then the RPi QLC+ restarts networking and now the "ping http://www.google.com" command shows a successful internet connection. Now I can do any upgrade via Network (Massimo's files as well as "apt-get update" for example).

The commands you'd mentioned provide now:

Code: Select all

root@raspberry-pi:~# ip route
default via 192.168.178.1 dev wlan0
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.36
root@raspberry-pi:~#

and

Code: Select all

root@raspberry-pi:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 wlan0
192.168.178.0   *               255.255.255.0   U     0      0        0 wlan0
root@raspberry-pi:~#

So this is a temporary solution to get the needed internet connection...
... because after any restart of the RPi QLC+, this connection is lost again, but can be retrieved fortunately by "service networking restart".

I would like to get confirmed, that this is normal for the "Network configuration" of my RPi QLC+, but I would know gladly, what "workflow" other users of this wonderful piece of software are using during "Network configuration", if they use the WLAN too...

Frank

[plugz]

default via 192.168.0.1 dev eth0

That's why you can't access anything (except devices with IP range 192.168.178.XXX) through the WLAN interface. The raspi tries to use the eth0 interface for internet access.

[pengumaniac]

It's apperently an error - lets say in OSI Layer 8!

Frank, please reread Massimo's words about factory settings, did he say you must use them here?
USE YOUR BRAIN and simply replace 0 with 178 (GATEWAY: 192.168.178.1)!!!
by repeating the same procedure

Instead of playing around with beauty colored lights & cute tiny PCs, maybe have some research about Debians ifup by /etc/network/interfaces, stanzas, gateway definition in the examples, the remains could be conjectured in the 1st # route response like plugz has already noticed.
Further, more interesting for you:
-what do the digits 192.168. mean (IPv4 addresses)?
-why is there relationship to the word private?
-what is the difference between Static IPs and DHCP
-what indents Subnets?
-and WTF is a gateway?

Aid: find the green colored words in the text above and copy them into google's SF, perhaps some of them together at a single blow...

If I think about, that persons like you should later pay for my pension!?
OMG, please throw some brain from heaven!
There are always social/community workers needed, by your needs of affiliation and communication this wouldn't be a bad choice, just give your equipment to charity.

SCNR...

@moderator: pls EoT solved (or even unresolvable)

[Frank]

It's apperently an error - lets say in OSI Layer 8!
...
If I think about, that persons like you should later pay for my pension!?
OMG, please throw some brain from heaven!
There are always social/community workers needed, by your needs of affiliation and communication this wouldn't be a bad choice, just give your equipment to charity.

SCNR...

@moderator: pls EoT solved (or even unresolvable)

Well roared, lion. *)
*) William Shakespeare, A Midsummer Night's Dream, Act 5, Scene 1


Dear pengumaniac,
I didn't ask you any question but you'd answered nevertheless...
So I should hope that there are another 30 years (or so) for you until you'll draw a pension, to have enough time to transfer your valuable knowledge to such stupid guys like me!...
... alternatively - if there isn't "enough" time until your pension - I should change my profession to nursing service for example, to stay near by you and could get more useful information about configuration of networking!

But seriously, the following configuration (content of the /etc/network/interfaces file) is working "against expectation"... (I really don't know why):

Code: Select all

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
  address 192.168.0.252
  netmask 255.255.255.0
  gateway 192.168.178.1
auto wlan0
iface wlan0 inet dhcp
  wpa-ssid HBL11-16
  wpa-psk 9543************

Now I can have both
- direct access from my PC (Point-to-Point) to the RPi QLC+ (wired by ethernet cable, without using any router!!!)
and
- access via WLAN (again from my PC, a smartphone for example, ...) using the router.

This configuration permits internet Connection via WLAN all the time, without the need of the command "service networking restart" after each restart! Excellent!

But be aware:
After Network upgrade, the RPi QLC+ has switched back to its "factory defaults", so it isn't accessible firstly!


@Massimo:
Please forgive me! Two remarks concerning "Network configuration" via Web interface of the RPi QLC+:

1.
"Network configuration" doesn't work independently for the two interfaces:
If "eth0" is reconfigured again (button "Apply changes" is pressed) the values of wlan0 are deleted (inside /etc/network/interfaces file) and have to be entered again.

2.
The values of wlan0 (if "Dynamic (DHCP)" is chosen) are not shown again after any restart (but not lost inside the /etc/network/interfaces file).

@All:
Am I the only one who "couldn't" understand the procedure of configuring that Network interface? Should one describe the produre once again step by step? Or is this only waste of time...

Thank you for your patience!
Frank

[pengumaniac]

Dear Frank,
thx for validation & sry for the shouting at you - I only hate, to need to tell sth twice.
That and TMI with repetitions & missing the essentials can make me turn out my snarkiest side, so it wasn't quite easy to keep my temper.

As "BDU-Prevention" is always a serious part in programming, OSI-L8-err is occasionally the jolliest euphemism derived of that kind of blunders - you shouldn't take it too private,
I didn't intend to take it synonym to the word with the 10 right in the middle of it...
Only wanna wake you up. I hope you hold it not against me forever and a day!
And my pension, now - I'm prepared for the worst (http://www.bonnaparte.de/5470) - thx for your offer, but I hope that I can shun away that.

See my interventions like "I've seen that at just the right moment", for the purpose of exoneration - as I have to spend a Dinner to Massimo anyway - I think he's glad about that and can himself concentrate at the really serious things to do.

So what about an simple input you have to do in rare times of upgrades vs. the efforts to optimize such trivia. Don't you think about the amount of all testers tests running into the same gap?
I myself still have to patch each new version, caused by a buggy "JMS usb2dmx" Interface, on two machines.
But I also had soon found some help here, and if that theme isn't further from interest of others, I can live with that workaround...


Enough Off Topic, now my RPi has returned, only the Rii-keyboard is even lost somewhere in the materials of the exhibition stand...
Lets do some subtle, fancy work:
(maybe Massimo finds - at a very very boring day - the following worth to utilize...)

We recapitulate:

• you're in the need of using two different subnets (perhaps you're not allowed by daddy to change PC's IP)
• you maybe want to use RPi NIC via DHCP, wired to the Router if the wlan-dongle is once dead
• you need on the same NIC a fallback to a static IP, if your PC is connected + wlan via DHCP to www
• you should have only wlan workin , too

As care, you should always have a keyboard connected to the RPi, making such adventures if you haven't something like that:
[exturl]http://willem.aandewiel.nl/index.php/sh ... pi-english[/exturl]
(Mine is a little bit smarter, fitted between watterott's 2,8" and card slot by the needs of only one tiny button.)
Furthermore you should know, where to find a Bash Prompt - just why?

Here is my preliminary ultimate /etc/network/interfaces dealin' that way (Never mind the wlan part, use your setting)
and perhaps to try it, screw down timings on dhcp-calls (RPi->DHCP Discover) first
in /etc/dhcp/dhclient.conf

Code: Select all

timeout 30;
retry 30;	#?
#reboot 10;

Here we can also see what's all beeing requested by a DHCP Request:

Code: Select all

request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, domain-search, host-name,
	dhcp6.name-servers, dhcp6.domain-search,
	netbios-name-servers, netbios-scope, interface-mtu,
	rfc3442-classless-static-routes, ntp-servers;

$ cat /etc/network/interfaces

Code: Select all

auto lo                                                                                                                                                
iface lo inet loopback                                                                                                                                 
                                                                                                                                                       
auto eth0                                                                                                                                              
allow-hotplug eth0                                                                                                                                     
iface eth0 inet dhcp                                                                                                                                   
    gateway 192.168.178.1     # needed, but single here isn't satisfying the wlan dhcp                                                                                                                        
                                                                                                                                                       
auto eth0:0                                                                                                                                            
allow-hotplug eth0:0                                                                                                                                   
iface eth0:0 inet static
    address 192.168.0.252
    netmask 255.255.255.0
#	gateway 192.168.178.1	# 1st attempt: single here isn't satisfying the wlan dhcp; not needed
    
auto wlan0    
allow-hotplug wlan0
iface wlan0 inet manual
    gateway 192.168.178.1	# needed, too
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

it was not really able to hotplug:
a) plug in the cable to the PC ...
b) swap cable from PC to Router (after the Discover this doesn't make sense,anyway)
...after RPi's start up completed, both attempts killed the wlan connection (ssh, which I had opened to control)!
Nevertheless I could connect then from PC...

Anyhow, I don't understand the behavior - because in the original, factory file with both on dhcp
there is no gateway mentioned (I think, this is satisfied by DHCP Request-> routers, normally).
But here, with the additional Static IP, I need to set it just there, where I didn't expect...


HTH, Peace?

Greets, Manfred

[mcallegari]

Frank

Am I the only one who "couldn't" understand the procedure of configuring that Network interface? Should one describe the produre once again step by step? Or is this only waste of time...

I think you can answer this question yourself. Do you see other users asking for step-by-step guides related to Linux configurations ?

In some cases it's the opposite: users share their experience with the RPi in this forum. For example: http://traylorhead.com/wp/my-projects/r ... g-software

After 17 posts you still seem not able to understand how Linux networking works, so let me Google that for you and report the relevant results here:
Official Debian documentation: https://www.debian.org/doc/manuals/debi ... /ch05.html
Official Debian wiki: https://wiki.debian.org/NetworkConfiguration
A problem similar to yours: http://raspberrypi.stackexchange.com/qu ... d-ethernet (they use wpa_supplicant instead)

In general though, using two interfaces on the same network is a bad idea, unless you know exactly how to configure routes, metrics, etc.
Such particular case is out of scope for QLC+, so manual configuration is needed.

The web interface has been implemented to use one interface at the time. I'll see if there are some missing cases and eventually fix them.
Sorry but I'm not going to reply to this thread anymore. I think I've dedicated enough time to it...time that I need to spend on QLC+ 5 if we ever want to see it some day.