Wired network Disconnected

Greetings,

I am a BBB newbie and trying to set it up as linuxcnc per:
http://bb-lcnc.blogspot.com/p/machinekit_16.html. Base distro is
Debian Wheezy.

My host “console” is ubuntu 12.04 LTS running as a VM in OS X.

After booting the BBB from the SD card, connecting it to the VM,
and running “ifconfig eth1 192.168.7.1” I am able to ping 192.168.7.2
and ssh as either the root or linux user.

However, shortly thereafter ubuntu displays “Wired network Disconnected”,
the ssh session is frozen, and eth1 no longer shows inet addr:192.168.7.2.
The message keeps appearing periodically.

I have added udev rules via mkudevrule.sh but no joy.

Any ideas? This behavior does not occur when I boot the default image
from eMMC (and I do not have to manually add 192.168.7.1 either).

Thanks, -K-

Why the double post?

Gerald

I am the moderator. I generally give answers to question only if I have an answer. I will leave it up to others to help you if they can. Maybe the providers of the image you are using will jump in and answer your question.

Gerald

.

is this ethernet or USB g_ether / g_multi ? IF the latter, get rid of USB networking, at best its flaky, at least from what I have noticed on Wheezy.

If this is an actual problem with ethernet, you might start by changing out the ethernet cable plugged into the BBB ( easiest to check / do if you have a spare cable ), also double check to make sure the connectors on both ends are plugged in securely. Short of this, you’re potentially in for a world of network troubleshooting . . .

How are you networking to the BBB? The system is setup to use wired
Ethernet and DHCP. If you want something different, you need to edit
/etc/network/interfaces as usual on a Debian based distribution.

If you're using USB networking, I highly recommend you use the real,
physical Ehternet port on the BBB...that's why it's there. Running
Ubuntu from a virtual machine on a Mac talking via USB network
connection to the BBB is basically unsupported.

That said, the reason you have to run ifconfig on the MachineKit image
and you don't on the default Angstrom is probably because I'm not trying
to support USB networking with MachineKit, so there's no DHCP server
setup trying to make the USB networking "plug and play". The existing
USB networking setup is apparently left-over from the RCN imaging scripts.

/me: wanders off to disable USB networking in future image builds...

I’m having a similar problem, with a twist.

Host computer: Ubuntu 12.04
Black Bone: Angstrum 2013-06-20 image from http://beagleboard.org/latest-images

If I boot the bone from the onboard 2G of flash, all works well.
If I boot from the SD card (same image, freshly reflashed) the network between the host and bone connects, the shortly disconnects. It continues to connect/disconnect from then on.

Any ideas why I get a different behavior depending on where I boot from?

–Mark

Mark,

Question. How are you powering the board?

Gerald

Gerald:
I’ve tried both USB powered and external 5V. Same results.

–Mark

Gerald, is there any possibility of hardware conflict here ? Noise ? I am just wondering, because this sounds more like a software configuration issue, but on the other hand seems like it could be caused by noise ? I really do not know, but would like to see whats up as this could be related to my own g_ether / g_multi / RNDIS issues i mentioned above.

Oh, and just to make things absolutely clear. The onboard ethernet has always been 100% rock solid for me no matter what I do.

I have a 'scope here I can make measurements here if needed.

Ditto on the onboard ethernet. It’ rock solid.

–Mark

Here’s some more data:

I took the SD card from the BBB and moved it to a BBW. Same results, the network keeps dropping.

Could the image installed by the eMMC flasher be different than what’s installed on the CD card?

–Mark

I had some very…odd network issues with my BBB. Periodically when it was running on the network, all other pc’s on the network would lose their network connection[a mix of windows8, windows 7, and linux mint 14 - a ubuntu derivative]

Unplugging the BBB would result in the network magically start working again.

Checking the logfiles on my BBB I noticed that I had forgotten to set the date, so all the timestamps where wildly offdate. Since I needed the date to be realitvely current for other items, I installed the ntpd server[sudo apt-get install ntp] so that the daemon could keep the system clock up to date.

Oddly enough, after doing that all my network issues disappeared. I’m guessing the problem is somehow related to the dhcp client running into issues with the timestamps - but that that is just a guess.

I still have no clue what caused the problem, but at least it has stopped for me. Figured I’d throw the suggestion out there as it is an easy work around.

Interesting. I was under the impression that the images were the same. From a HW standpoint, only delta I can see is the increased current brought on by the SD card. That is why I asked about power.

If you can take the latest test load, 8_21, where SD is supported, you can boot from eMMC and beat the crap out of the SD card to see if that has an affect. Maybe copy a big file or something.

Gerald

Mark, is the onboard ethernet configured with an IP address as well ? I had my own eth0 configured at the same time I was attempting RNDIS.

Also last time I used RNDIS, I mapped the RNDIS in Windows (Win7 x64 ) Through Virtualbox as an eth device. Where the VM running debian wheezy would just pick it up as a regular ethernet interface ( eth1 ). MY connection with it was intermittent like what you all are experiencing. Except when I would ping the BBB from the host, and then BBB to host, my connection would start working again. Of course, it would stop working again after a little while.

What we all seem to share in common is booting from uSD card. Although I run Debian wheezy, with semi recent build from RCN.

root@arm:~# uname -a
Linux arm 3.8.13-bone21 #1 SMP Mon Jun 24 23:57:02 MST 2013 armv7l GNU/Linux

And for you Gerald . . .

root@arm:~# uptime
12:04:33 up 23 days, 11:57, 2 users, load average: 0.00, 0.01, 0.05

Still going strong and connected to freenode :slight_smile:

Hmm, also forgot to mention for some time I was thinking this could be network metrics related, but yeah I am not a network expert, was just me wondering.

Yup, the onboard ethernet is configured as well. I’ve tried unplugging the onboard eithernet and I get the same results.

Right now I’m writing another SD to see if the card make a difference.

–Mark

I had some very…odd network issues with my BBB. Periodically when it was running on the network, all other pc’s on the network would lose their network connection[a mix of windows8, windows 7, and linux mint 14 - a ubuntu derivative]

Unplugging the BBB would result in the network magically start working again.

Running Angstrom on a BBB that I got just a couple of days ago, I experience the same behavior, primarily with the BBB plugged into a Windows XP Pro machine.

Checking the logfiles on my BBB I noticed that I had forgotten to set the date, so all the timestamps where wildly offdate. Since I needed the date to be realitvely current for other items, I installed the ntpd server[sudo apt-get install ntp] so that the daemon could keep the system clock up to date.

I set this up using the method shown by Derek Molloy’s post, “Automatically Setting the Beaglebone Black Time Using NTP”. And to be sure that the time is set, I have a variant of his ee402/scripts/StartUSBNetwork (modified for the North American instead of the Irish NTP pool: north-america.pool.ntp.org) that I run by hand after logging in. It frequently hangs for a long time, since it can’t find the pool (because it can’t connect to the name server.) [See Molloy’s “Getting Started – USB Network Adapter on the Beaglebone” for details.]

These things work only if the BBB is able to see the name servers (e.g. 8.8.8.8) and, especially, the gateway (192.168.1.7), which I’ve found it frequently cannot, both when connected to a Windows 7 and to a Windows XP computer. FLAKY!!

Right now, it’s working just fine, but for the previous dozen times earlier today, it failed…even trying reboots of the Windows machine. Yes, very FLAKY!!

Oddly enough, after doing that all my network issues disappeared. I’m guessing the problem is somehow related to the dhcp client running into issues with the timestamps - but that that is just a guess.

I still have no clue what caused the problem, but at least it has stopped for me. Figured I’d throw the suggestion out there as it is an easy work around.

Thanks for sharing your experience. I hope someone can provide some insight about the cause and–even better–a solution. This is getting old.

-R