After flashing jetpack 3.1 to my TX2 devkit, the network interface does not seem to link in software or hardware. The link light stays off (I have gone through several switches and cables) and the switch shows no link on the port either. I attempted to fix it through ifconfig but no matter what was done, I cannot seem to be able to get it back and working. Any help would be greatly appreciated.
Thanks,
Cole
The link light tends to make me think of hardware, but what does the output of “ifconfig” show? More importantly, do you have a separate router, or is your PC the router? Can you see the logs to see if a DHCP request is being made? Additionally, what is the output from this:
dmesg | egrep -i '(ether|inet|network|igb)'
Here is the output from ifconfig.
eth0 Link encap:Ethernet HWaddr 00:04:4b:8c:7c:2a
UP BROADCAST 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:42
wlan0 Link encap:Ethernet HWaddr 00:04:4b:8c:7c:28
inet addr:192.168.1.143 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::37c2:509:7b7d:6d46/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4009 (4.0 KB) TX bytes:8154 (8.1 KB)
here is the output from the special command
nvidia@tegra-ubuntu:~$ dmesg | egrep -i '(ether|inet|network|igb)'
[ 0.241410] iommu: Adding device 2490000.ether_qos to group 18
[ 2.662909] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 2.662945] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[ 2.662947] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 2.664222] usbcore: registered new interface driver cdc_ether
[ 2.667153] eqos 2490000.ether_qos: Setting local MAC: 0 4 4b 8c 7c 2a
[ 19.273935] dhd_inet6_work_handler: Adding host ip for NDO failed -23
as to the logs part, I have no clue how to get to those unless it is the system log.
After you see eqos setting MAC you should see something like this:
[ 20.794120] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Instead you see DHCP fail (apparently using an IPv6 address), but this is WiFi. I am thinking that perhaps there is a configuration issue where it is trying to use WiFi instead of wired…without attempting to use wired.
The wireless interface seems to be the only functional one thus far. I did have to manually connect it but nothing shows up indicating that dhcp is failing. This part is more of a hardware question, but could the magnetics or interface be fried by hooking it up to a PoE switch? This is another possible variable that may have caused this. The switch is a standard Dlink PoE and hasn’t fired anything else but I am laying the possibility out there.
There are the more common IPv4 addresses, and then there are addresses which will become more visible over time due to the internet addresses running out…those are IPv6. The version which failed is IPv6, and this would be normal if ordinary IPv4 addressing is used.
The point is that having set up WiFi the way it is may have caused NetworkManager (or whatever is doing configuration) to stop trying to bring up the wired ethernet…you may need to just research how to make wired ethernet run even if WiFi is up…or to get it to try wired before trying WiFi. It seems possible that everything is working fine, but that wired ethernet was told to not try to set up because it thinks WiFi is doing the job.
That is strange then because the issue started well before I configured the wireless interface. Im wondering if it could be an interaction with jetpack then. Ill have to dig around on that but when the device was going through the flash, it could not find an ip for it and I panicked to keep the install from timing out so I kicked it on. could that still be the issue?
Keep in mind that if the system were trying to use WiFi instead of wired that it might not matter if WiFi never came up (it is a configurable setup as to how to behave when WiFi drops…upon startup it might be a different configuration for whether or not to move on to wired when WiFi fails…or vice versa…I find NetworkManager and some of the other configuration which interacts with WiFi to be annoying). I don’t know, I’m not much of a WiFi person.
I also do not know all of the interactions with JetPack for networking setup, but it does try to configure some parts of wired ethernet and the router (it is DHCP), especially if the router is your PC. It is possible there was an interaction which is related to this. On the bright side there is no reason you can’t run the non-flash part of JetPack at any time after the system is up just to poke around and see what options there are.
What is your current wired router, is it the PC, or is it a router appliance?
So far as options go, do you have anything on the Jetson which would preclude simply flashing again?
My current setup is an airport extreme as the router which goes through a switch to get to the computer and the jetson. For the most part the air port is in a default configuration (no subnets or ipv6 enabled). In terms of the software on the jetson, I have not done any additional installs and already tried re-flashing the jetson.
So how is it wired:
switch->internet
router->switch
Jetson->router
PC->router
# OR:
router->internet
switch->router
Jetson->switch
PC->switch
Do you have some sort of web interface or log accessible on the router? It would be very useful if you can something showing when a DHCP request arrives…even better if it says not only whether an address was issued, but also why not issued for cases of failure.
The thing about reflashing is that if you want to debug via logs on the router, then you need to check logs with no configuration changes…and then after an attempt at configuration change. Currently you can’t do that because of WiFi configuration changes.
Second config.
As to the logs let me see about that.
Edit:
there is nothing in the log to suggest a connection was attempted other than the wireless connection. no dhcp errors as far as i can tell nor any other error. the only thing in the logs that i get on boot is
connection accepted from [device wifi MAC address]
Edit 2:
There is also this weird thing that keeps happening where the eth0 interface will “connect” but at a strange ip that the router cannot give out with no default route
here is an Imgur Link to the connections: Imgur: The magic of the Internet
The 169 address is actually normal when a DHCP times out and it goes into a “loopback” mode. This gives an address, but the address goes nowhere but the local computer. The fact that it gets an address, and then removes it, tends to imply that software has been told to not allow the interface to be configured.
What kind of firewall software might be running? Given that there was not even an attempt at DHCP configuration going to the router it has to be assumed that either the request went out and got blocked, or else the request never went out. Because a 169 address was issued momentarily, either could be correct.
To my knowledge there is no firewall on the router configured. It should just be off (if there is one). Tomorrow morning I am going to bust out the oscilloscope and make sure that no damage was done to the magnetics. That should give me a good idea as to whether the problem is physical or software.
A DHCP request won’t last long, neither will ARP, but if you have a storage scope set to trigger and record you should catch something. If you get any activity I would suggest flashing again…not as a fix, but just to be sure all configuration and setup is default…then testing for DHCP request.
as a matter of fact, I am getting a signal however it looks more like an “is anyone there” request from the switch as it seems to be a regular interval of every second or so (my scope isn’t fast enough to decode any info). It did prove however that the magnetics do seem to be working so software is the most probable at this point.
Edit:
It only gets stranger from here. When the board is forced to reset and put into USB recovery, the wired port linked for about two minutes but never showed any activity… This goes waaay beyond what I even know to do at this point
I would flash again to be sure you start with a configuration known to send out DHCP on wired ethernet. I would not configure WiFi (or disable it). Then do the DHCP checks again on the router. Possibly you could reboot the router in case there is an ARP table cache getting in the way.
just noticed, there is another thread going around about having similar issues after flashing. something to do with the pinmux maybe? i did re-flash but i might just try and get a defaulted router, connected to the internet, with my machine and the jetson as the only two things.
You may be looking at another thread where the carrier board differs, or in which the device tree was altered. A default flash on a developer carrier board should not need any device tree adjustment.
they were indicating that it was in fact the standard carrier but wash having issues with the latest l4t distro. would rolling back to 3.0 possibly show if it was a software issue. i might try that next.
Edit:
Can confirm that when placed into USB force recovery, the network port link light comes on but no actual link is established. The switch nor the network detects a link.
I also re-ran the dmesg command and now the last line reads
Bluetooth: BNEP (Ethernet Emulation) ver 1.3