LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.

Notices


Reply
  Search this Thread
Old 04-12-2016, 06:37 AM   #1
amrbekhit
LQ Newbie
 
Registered: Apr 2016
Posts: 2

Rep: Reputation: Disabled
No response to DHCP discover packets sent on eth0


Hello all,

I'm trying to get ethernet working on a Build-root based embedded system using an AT91SAM9X25 SoC. Using the manufacturer-provided linux image, the ethernet connection works fine, getting an IP via DHCP. However, I am building my own kernel and rootfs using buildroot, and unfortunately, I cannot seem to get the ethernet to work.

After a fresh boot, I bring the interface up using the following:

Code:
ifconfig eth0 up
I then run tcpdump in the background:

Code:
tcpdump -i eth0 &
I then try to get an IP via DHCP:

Code:
udhcpc -i eth0 > /dev/null
The output of tcpdump seems to imply that packets are being broadcast:

Code:
12:05:28.621929 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
12:05:31.625962 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
12:05:34.633663 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
Yet despite this, I don't seem to get any response back from the DHCP server, and the ethernet does not function. In comparison, running tcpdump while running the factory provided linux image and using dhclient results in the following dump:

Code:
11:31:29.245187 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
11:31:29.246630 IP 192.168.51.6.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
11:31:29.704547 ARP, Request who-has 192.168.51.6 tell 192.168.51.62, length 28
11:31:29.704947 ARP, Reply 192.168.51.6 is-at 00:15:5d:63:ac:00 (oui Unknown), length 46
11:31:29.705017 IP 192.168.51.62.39341 > 192.168.51.6.domain: 34591+ PTR? 0.0.0.0.in-addr.arpa. (38)
11:31:29.705768 ARP, Request who-has 192.168.51.62 tell 192.168.51.6, length 46
11:31:29.705847 ARP, Reply 192.168.51.62 is-at 70:b3:d5:ba:b8:90 (oui Unknown), length 28
11:31:29.706081 IP 192.168.51.6.domain > 192.168.51.62.39341: 34591 NXDomain* 0/1/0 (117)
11:31:29.707234 IP 192.168.51.62.36164 > 192.168.51.6.domain: 63607+ PTR? 255.255.255.255.in-addr.arpa. (46)
11:31:29.707857 IP 192.168.51.6.domain > 192.168.51.62.36164: 63607 NXDomain* 0/1/0 (127)
11:31:30.704424 IP 192.168.51.62.47902 > 192.168.51.6.domain: 28068+ PTR? 62.51.168.192.in-addr.arpa. (44)
11:31:30.705122 IP 192.168.51.6.domain > 192.168.51.62.47902: 28068 NXDomain* 0/1/0 (132)
11:31:30.879955 IP6 fe80::fd90:22f:f8c9:ebf8.546 > ff02::1:2.547: dhcp6 solicit
11:31:31.704825 IP 192.168.51.62.38999 > 192.168.51.6.domain: 24273+ PTR? 8.f.b.e.9.c.8.f.f.2.2.0.0.9.d.f.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
11:31:31.734521 IP 192.168.51.6.domain > 192.168.51.62.38999: 24273 NXDomain 0/1/0 (160)
11:31:31.780364 IP6 fe80::1906:4685:a3b:b9f7.546 > ff02::1:2.547: dhcp6 solicit
11:31:32.070593 IP mechtron-accts.mech.local.netbios-ns > 192.168.51.255.netbios-ns: UDP, length 50
11:31:32.524140 ARP, Request who-has 192.168.51.253 tell mechtron-26.mech.local, length 46
11:31:32.525810 ARP, Request who-has 192.168.51.253 tell mechtron-26.mech.local, length 46
There is likely to be some other traffic in there, but at least you can see that the DHCP server is responding to the DHCP discover packet (highlighted in bold).

So, I know that the hardware, the ethernet cable, the router, etc are working fine. The issue seems to be in the rootfs image/kernel that I'm compiling. What could cause this issue?
 
Old 04-13-2016, 04:03 PM   #2
Wells
Member
 
Registered: Nov 2004
Location: Florida, USA
Distribution: Debian, Redhat
Posts: 417

Rep: Reputation: 53
What is the MAC address of eth0 once it is booted up? I am wondering this because I have seen a number of cases where the initial boot and install of a machine will have one ethernet device as eth0, but once the machine is up and running on the installed image from a harddrive, your ethernet devices will get scrambled and you will be trying to DHCP out of a different port.

Another thing to look at is which ethernet devices have link (perhaps a quick scan through dmesg output)
 
Old 04-14-2016, 01:38 AM   #3
blue_z
Member
 
Registered: Jul 2015
Location: USA
Distribution: Ubuntu, Lubuntu, Mint, custom embedded
Posts: 104

Rep: Reputation: Disabled
Quote:
Originally Posted by amrbekhit View Post
However, I am building my own kernel and rootfs using buildroot, and unfortunately, I cannot seem to get the ethernet to work.
...
So, I know that the hardware, the ethernet cable, the router, etc are working fine. The issue seems to be in the rootfs image/kernel that I'm compiling.
I would test using a static IP address before worrying about DHCP.

In actuality you don't even know if Ethernet frames are hitting the wire. You would need to examine the actual output (e.g. Wireshark on an external host), rather than an internal tcpdump.

Quote:
Originally Posted by amrbekhit View Post
What could cause this issue?
The most common cause I've seen has been a misconfiguration of the MII/RMII interface between the EMAC and PHY.

Last edited by blue_z; 04-14-2016 at 01:49 AM.
 
Old 04-20-2016, 10:28 AM   #4
amrbekhit
LQ Newbie
 
Registered: Apr 2016
Posts: 2

Original Poster
Rep: Reputation: Disabled
@wells: The manufacturer of the board I'm using happens to store the MAC address as a u-boot environment variable. I've compared the environment variable and the MAC address reported by ifconfig eth0 and they are identical, so it doesn't look like there's an issue with the MAC address.

@blue_z: I can't event get static IP working. I'm using u-boot and tftp to transfer files from my host development PC and the device, so I've got the host PC ethernet port set up using static IP (192.168.100.100, netmask 255.255.255.0), and in u-boot the device is configured to use 192.168.100.200. This link works fine, so I'm happy that physically, there's nothing wrong. When I boot into Linux, I then try and configure the unit to use the same static IP address:

Code:
ifconfig eth0 192.168.100.200
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
# macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 70:B3:D5:BA:B8:90
          inet addr:192.168.100.200  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::72b3:d5ff:feba:b890%3068699416/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:39 Base address:0xc000
Yet, I cannot ping the host computer at 192.168.100.100 at all. Running wireshark on the host computer on that network interface doesn't show any packets originating from the embedded device.

Quote:
In actuality you don't even know if Ethernet frames are hitting the wire
I agree - I suspect that this might be the issue here. You mentioned that perhaps there might be a a misconfiguration of the MII/RMII interface between the EMAC and PHY.

I've opened up the embedded device and had a look at the PHY chip. It's a DAVICOM DM9162IEP. I've had a look at the PHY Device support and infrastructure menu in the kernel menuconfig and the "Drivers for Davicom PHYs" options is enabled (CONFIG_DAVICOM_PHY). However, looking at the help text for that option shows that it only supports the dm9161e and dm9131 - I don't know whether the DM9162I is backwards compatible with any of these. This may be the cause of the issue - perhaps the manufacturer-provided kernel had a custom patch enabling support for that chip. I certainly couldn't find anything online that would indicate whether or not that particular chip is supported in the mainline kernel, or even a patch for it.

Other than this potential issue, is there anything else I can check to determine if there is a problem between the MAC and PHY?
 
Old 04-21-2016, 07:58 PM   #5
blue_z
Member
 
Registered: Jul 2015
Location: USA
Distribution: Ubuntu, Lubuntu, Mint, custom embedded
Posts: 104

Rep: Reputation: Disabled
Quote:
Originally Posted by amrbekhit View Post
I agree - I suspect that this might be the issue here.
Why the tentative opinion?
Why can't you make a definitive conclusion, and proceed from there?
Didn't you sanity check your Wireshark test?
Since you claim there's an "original" kernel and U-Boot that have functional networking, this should be trivial to confirm, and probably not that difficult to solve.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Run application before DHCP Client DISCOVER/REQUEST mpaylaga Linux - Networking 2 02-04-2016 07:35 PM
how to discover dhcp ? wakatana Linux - Networking 2 10-08-2009 04:52 PM
Discover DHCP clients on a subnet crackpipe Linux - Security 19 08-05-2009 04:53 PM
cannot dhcp discover after updating kernel, hangs on inetd precision Debian 0 06-04-2006 09:58 PM
Problem with DHCP discover mavinac Linux - Networking 1 04-28-2005 07:27 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer

All times are GMT -5. The time now is 12:11 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration