Debian Squeeze Network Issues

[nightmare55]

I set my RPi Debian Squeeze to have a static ip strangely when in GUI mode the connections is very slow.. and at times it also says network host unreachable, when i don't boot into GUI, the connection is fine i can ping any website or machine and the ms is around 20.

Anybody know what the issue could be?

[abishur]

Are you using the built in ethernet or a different one?

Also would you mind posting the contents of your /etc/network/interfaces file?

[rotheroe]

I'm having the same problem. As far as I can tell it's a memory use problem.

My RPi shows 192 Mb available on boot (64 Mb is being used by the GPU presumably).

Boot to text screen and only about half the mem is used. If you startx then the net won't work or it's incredibly slow (15 sec pings). Turned on swap and it didn't help.

Next time I get to it, I'll be looking at reducing mem requirements on boot and thinning down x programs.

[nightmare55]

Ok, please let me know how you get on and if you find a solution. BT has exchange issues so I have no Internet at the moment so can't test anything.

[sandrokan]

I have exactly the same network problem (I use the built-in network interface)
Under windows the net is not working and even if I do a simple ifconfig from LXTerminal it takes ages. If I shut down Xwin everything works fine.
It seems specific of the net interface since if I run other programs or if I monitor with top I can see the cpu used at 7% and a lot of free mem (the swap even if it is available is not used)

[Snowpuddles]

I have this same issue, without starting x, i can connect just fine, download and everything. But as soon as i get into lxde, everything times out, even in the terminal. Any tips?

[vipercomp]

Any solution yet? I have the same problem with Debian but not with Fedora 14.

[sandrokan]

Ok guys. I found the solution (at least for my configuration).
I used to use an external USB hub (7 ports) with an independent power supply.
If I take out the USB hub and I connect keyboard and mouse directly to the pi everything is working fine.
I still don't understand why there is this problem (the pi is using a power supply givin 1.3A and the USB hub is using another power supply giving 2A) but at least now I can use X.
I hope this will help you all.
Best
Sandro

[bredman]

This is a known issue with power supplies which cannot provide enough power. When running at low CPU load there is no problem. But when the CPU load reaches 100% (for example when starting LXDE) the Ethernet port does not have enough power available to keep the network connection open.

If your power supply is good quality, I would suspect your power cable.

[marsman2020]

This is a known issue with power supplies which cannot provide enough power. When running at low CPU load there is no problem. But when the CPU load reaches 100% (for example when starting LXDE) the Ethernet port does not have enough power available to keep the network connection open.

If your power supply is good quality, I would suspect your power cable.

I think there is a larger issue here, that people are disregarding as "it's the power supply".

Read sandrokan's post:

Ok guys. I found the solution (at least for my configuration).
I used to use an external USB hub (7 ports) with an independent power supply.
If I take out the USB hub and I connect keyboard and mouse directly to the pi everything is working fine.
I still don't understand why there is this problem (the pi is using a power supply givin 1.3A and the USB hub is using another power supply giving 2A) but at least now I can use X.
I hope this will help you all.
Best
Sandro

Why would his configuration work *without* the powered hub but not *with* the powered hub?

I've had the same issue with my Pi - 'kevent 4 dropped' errors on the Ethernet when entering a GUI. I'm using the Touchpad 5.3V/2A power supply and a 24AWG power wire USB cable.

Folks who are having this issue, please check the output of 'dmesg' both before and after entering the GUI....

[Kmcfarland]

Same issue here - removing a 7 port Belkin powered USB hub from the equation restored networking to my GUI environment and returned terminal response within the gui to normal.

[vipercomp]

Well I would never have suspected that! I've changed the USB power lead and now it all works fine!

[marsman2020]

Same issue here - removing a 7 port Belkin powered USB hub from the equation restored networking to my GUI environment and returned terminal response within the gui to normal.

Which Belkin? I've tried 2 Belkin MultiTT 7 port hubs, and both killed the Ethernet. Checked TP1-TP2 with an oscilloscope and it was perfectly in spec, so it's some kind of software issue that throws the same errors as a hardware power issue.... See https://github.com/raspberrypi/linux/issues/29

[MotoBlue]

Same issue here - removing a 7 port Belkin powered USB hub from the equation restored networking to my GUI environment and returned terminal response within the gui to normal.

Which Belkin? I've tried 2 Belkin MultiTT 7 port hubs, and both killed the Ethernet. Checked TP1-TP2 with an oscilloscope and it was perfectly in spec, so it's some kind of software issue that throws the same errors as a hardware power issue.... See https://github.com/raspberrypi/linux/issues/29

Is it because the volt drop across the lead supplying power to the pi means that the voltage on the usb side of the polyfuse is greater than the pi supply voltage and current flows cooking the polyfuses.
Is it possible to go back to using your powered hub and measure across the polyfuse with your oscilloscope.

[ShaunB]

I'm not sure if what i see is exactly the same as the OP, but i have a suspicion the problem is not entirely power related.

My set up is a Belkin 4 port powered swivel hub, and old Sweex RT2500 chipset wifi key and currently powering the pi from a separate HTC 5v wall plug.

The Debian image is loaded on a 16gb micro sd and has been grown to fill the card.

Basically, my first set-up worked the best; this was with a keyboard & mouse receiver, and the Sweex wifi key. The only downside was that there was obviously a lack of power getting to the wifi key as the signal kept dropping out even though the router was a foot way. Browsing worked but it was slow.

So i plugged the hub in and added the wifi key to the hub. The key was live but WICD would no longer scan for gateways. This stumped me for days, until i happened to try an update before booting in to LXDE, and was surprised to see a perfect network response. then proceeded to install VLC and ALSA, all flawless.

Convinced all was working, booted in to LXDE, and suddenly no network again!

From this i can only deduce it would be something to do with the loading of LXDE and and how it handles the addition ports of the USB hub.

Can anyone think of why LXDE and the USB hub might conflict? does LXDE load seperate USB drivers?

[jbeale]

I wonder if this is the same problem being reported here, "Really odd wifi behaviour! LXDE kills it..."
http://www.raspberrypi.org/phpBB3/viewt ... =28&t=6928

[Kmcfarland]

Same issue here - removing a 7 port Belkin powered USB hub from the equation restored networking to my GUI environment and returned terminal response within the gui to normal.

Which Belkin? I've tried 2 Belkin MultiTT 7 port hubs, and both killed the Ethernet. Checked TP1-TP2 with an oscilloscope and it was perfectly in spec, so it's some kind of software issue that throws the same errors as a hardware power issue.... See https://github.com/raspberrypi/linux/issues/29

It is the same one mentioned under the problem Belkin hubs in the wiki: 7-Port Powered Mobile Hub - device labelled F4U018 - of course I didn't think to check the wiki as I was exploring my problem

http://elinux.org/RPi_VerifiedPeriphera ... d_USB_Hubs

[marsman2020]

I don't think this is a polyfuse issue. The polyfuses takes some period of time to re-crystalize and pass current again, but I can cause the issue to appear and disappear at will simply by starting and stopping the GPM service, with no delay for the polyfuse to reset itself.

I borrowed the oscilloscope and I have returned it. I know this is a development release of the Pi, but I've spent several hours of time doing the best I can to debug this issue and I'm really hoping someone responsible for the hardware/software will spend some time looking at this and give us some feedback.

The one last thing I might try is sacrificing a Mini USB cable to cut the +/- power lines and leave only the data intact.

[ShaunB]

I wonder if this is the same problem being reported here, "Really odd wifi behaviour! LXDE kills it..."
http://www.raspberrypi.org/phpBB3/viewt ... =28&t=6928

Perfect, this is exactly the same behavior as i have experienced. Many thanks for the link.

[NickT]

I think there is a grave danger of "It must be your power supply" being accepted as the answer to all network related problems with the Pi. It is rapidly achieving the status of an urban myth.
There is more than enough evidence of users with perfectly good power supplies showing a healthy 4.8V+ and seeing (1) : wifi adapters losing network connectivity and (2) high packet loss over wired ethernet. In both cases this occurs after the LXDE desktop has started. Again in both cases, running dmesg after the error has occurred will show :

smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118

This is a firmware problem - not the PSU. Googling for the above strings will lead to references to mixing high speed and low speed devices on the same hub. There has been an alleged fix for this. If it has been applied to the latest update (installed via RPI -update) then it doesn't work (I've tried it).

I wish I could offer something by way of a solution but I can't. I would just like to debunk the myth that it's always the PSU. The one thing I would say about powered hubs is that it's not a good idea to bring the +5(ish) volts from the hub into the Pi's USB port. If your hub puts out more than 5 volts, then you will have a clamped voltage of maximum 5 volts on one side of the polyfuse and something over 5 volts on the other - current will flow!

[abishur]

I think there is a grave danger of "It must be your power supply" being accepted as the answer to all network related problems with the Pi. It is rapidly achieving the status of an urban myth.

It's hardly as sinister as that. The truth is having read through most the troubleshooting issues the majority of the problem lied with the PSU. It doesn't make sense from a troubleshooting perspective to start with the most complicated and least common issue, but to start with the most common issue. Ergo, the first thing we check is the PSU. It's elementary my dear Watson

[NickT]

I think there is a grave danger of "It must be your power supply" being accepted as the answer to all network related problems with the Pi. It is rapidly achieving the status of an urban myth.

It's hardly as sinister as that. The truth is having read through most the troubleshooting issues the majority of the problem lied with the PSU. It doesn't make sense from a troubleshooting perspective to start with the most complicated and least common issue, but to start with the most common issue. Ergo, the first thing we check is the PSU. It's elementary my dear Watson

Agreed it make sense to check the voltage first but I did qualify my assertion with "known good power supplies". Would you agree that if you see the log lines that I mentioned in your dmesg output, that it's a firmware problem? If so, then perhaps a sticky along the lines of "seen this in you logs? then don't waste your money buying another power supply" might be good idea.

[abishur]

Agreed it make sense to check the voltage first but I did qualify my assertion with "known good power supplies". Would you agree that if you see the log lines that I mentioned in your dmesg output, that it's a firmware problem? If so, then perhaps a sticky along the lines of "seen this in you logs? then don't waste your money buying another power supply" might be good idea.

Sadly, many have asserted that they were using a good power supply only for it to turn out they didn't understand what the pi actually required (an issue I fear is being exacerbated by one of the distributors telling everyone to use a 500 mA PSU MAX ) which is why whenever someone starts off a post like that I ask them for the details of the PSU anyways.

Now neither this post nor my previous post are trying to say your specific issue has anything to do with your PSU which is why I didn't quote anything except that one line. I'm only commenting on your urban myth comment

I agree that a sticky is increasingly a good idea, but not about "don't waste your money" but more along the lines of "test this before posting, and when you post be sure to include this information" A tier 1 technical support so to speak that would solve... about 80% (rough guess) of the issues I've seen posted thus far.

[marsman2020]

I think there is a grave danger of "It must be your power supply" being accepted as the answer to all network related problems with the Pi. It is rapidly achieving the status of an urban myth.

It's hardly as sinister as that. The truth is having read through most the troubleshooting issues the majority of the problem lied with the PSU. It doesn't make sense from a troubleshooting perspective to start with the most complicated and least common issue, but to start with the most common issue. Ergo, the first thing we check is the PSU. It's elementary my dear Watson

I have collected extensive documentation (checked with oscilloscope) of how this can't be strictly a power issue in Issue #29 on the raspberypi/linux github, with links to ~7 (and counting, I am seeing ~2 more every days) separate threads on the forums here with people having similar issues that might not be power-related. Within these threads, new users are coming in each day and saying that they are seeing these types of issues. It has been observed in the Raspbian armhf build as well.

However no one involved in the maintenance of the Rpi kernel has commented on my open issue in the week that it's been there.

I agree people are being told "try a different x" and sent on what could amount to wild goose chases buying more and more hardware when this could be a software issue. The solution for me was to top using my powered hub and connect the wireless mouse/keyboard to the Pi directly. The Pi provides plenty of juice for them. This the exact opposite of what a lot of people are recommending on the forums and wiki which is to go get a powered hub.

[abishur]

I think there is a grave danger of "It must be your power supply" being accepted as the answer to all network related problems with the Pi. It is rapidly achieving the status of an urban myth.

It's hardly as sinister as that. The truth is having read through most the troubleshooting issues the majority of the problem lied with the PSU. It doesn't make sense from a troubleshooting perspective to start with the most complicated and least common issue, but to start with the most common issue. Ergo, the first thing we check is the PSU. It's elementary my dear Watson

I have collected extensive documentation (checked with oscilloscope) of how this can't be strictly a power issue in Issue #29 on the raspberypi/linux github, with links to ~7 (and counting, I am seeing ~2 more every days) separate threads on the forums here with people having similar issues that might not be power-related. Within these threads, new users are coming in each day and saying that they are seeing these types of issues. It has been observed in the Raspbian armhf build as well.

However no one involved in the maintenance of the Rpi kernel has commented on my open issue in the week that it's been there.

I agree people are being told "try a different x" and sent on what could amount to wild goose chases buying more and more hardware when this could be a software issue. The solution for me was to stop using my powered hub and connect the wireless mouse/keyboard to the Pi directly. The Pi provides plenty of juice for them. This the exact opposite of what a lot of people are recommending on the forums and wiki which is to go get a powered hub.

As I told NickT

Now neither this post nor my previous post are trying to say your specific issue has anything to do with your PSU which is why I didn't quote anything except that one line. I'm only commenting on your urban myth comment

Which is to say I wasn't commenting on your documentation at all. Now it's great that the solution for you was something different, but that doesn't change the fact that for the vast majority of people (at this time at any rate ) the issue lies in the PSU (or overdraw on the USB ports). To stop suggesting the number one issue because a handful of people didn't have that issue is crazy. That said, I do agree that I don't think the answer is to tell them to go and buy another PSU off the, but to *try* a different PSU if there is one available or a shorter USB cable if that's availble or to get a reading from TP1 and TP2 if they have a voltmeter or available or even to just list the ratings of their PSU if they can't do anything else. The heart of troubleshooting is to start with the simplest, most common issue and work your way out from there