Weird Ethernet behaviour

Moderators: mdrjr, odroid

Weird Ethernet behaviour

Unread postby DamianPe » Thu Aug 10, 2017 3:35 am

Hi!

Recently I found weird ethernet behaviour. I want to clarify that I am not a network specialist, I have only a general knowledge. Here is my setup.
Cable modem attached to wireless router via RJ45. All devices connected wirelessly to AP. I needed to connect my Odroid C2 to router via cable (Ubuntu minimal image does not contain packages for USB so I can not enable elan0, I have tu upgrade and install packages from internet). When I connect Odroid with cable, my whole network crashes. All wirelessly connected devices can connect to AP but not further. Odroid receives IP address via DHCP but cannot connect to internet either. When I disconnect Odroid from router, rest of devices can access internet again. I tried 2 different routers and two different OSes - Arch Linux and Ubuntu.
On RJ45 socket green LED is almost constantly on, orange is off.

What can be going on?
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Thu Aug 10, 2017 4:28 am

I assume you're using dhcp. Can you tell us what range is allocated by dhcp? Try these commands after plugging in the odroid:
Code: Select all
ifconfig
ethtool eth0
route -n
arp -an
tcpdump -n -i eth0 -c 100

Can you try allocating a static ip for the odroid?
Code: Select all
sudo pkill -9 dhclient
ifconfig eth0 192.168.1.35 netmask 255.255.255.0 up
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Fri Aug 11, 2017 12:39 am

Yes, I am using dhcp and this part works correctly.

Code: Select all
odroid@odroid64:~/Desktop$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1e:06:34:a2:b0
          inet addr:10.38.0.203  Bcast:10.38.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:6ff:fe34:a2b0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:20 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2284 (2.2 KB)  TX bytes:9958 (9.9 KB)
          Interrupt:40

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:4096  Metric:1
          RX packets:725 errors:0 dropped:0 overruns:0 frame:0
          TX packets:725 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:61861 (61.8 KB)  TX bytes:61861 (61.8 KB)

odroid@odroid64:~/Desktop$ ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: yes
        odroid@odroid64:~/Desktop$ route -n
        Kernel IP routing table
        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
        0.0.0.0         10.38.0.200     0.0.0.0         UG    100    0        0 eth0
        10.38.0.0       0.0.0.0         255.255.255.0   U     100    0        0 eth0
        169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
        odroid@odroid64:~/Desktop$ arp -an
        ? (10.38.0.200) at xx:xx:xx:xx:xx:xx [ether] on eth0
        odroid@odroid64:~/Desktop$ tcpdump -n -i eth0 -c 100
        bash: tcpdump: command not found


Any idea what is happening?
Code: Select all
odroid@odroid64:~/Desktop$ uname -a
Linux odroid64 3.14.79-108 #1 SMP PREEMPT Mon Feb 27 23:18:26 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux

Code: Select all
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial


Assignning a static IP changes nothing.

On current router I assign addresses 10.38.0.201 to 255 (200 is router itself) with netmask 255.255.255.0.
On second router I assign addresses 192.168.1.2 to 255 (1 is router itself) with the same netmask - the same result - all traffic is blocked.
I tried the same with Arch Linux with the same result so I believe this error follows Odroid board rather than OS or router.
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Fri Aug 11, 2017 1:42 am

Can you install tcpdump and post the output of a packet capture?
Code: Select all
sudo apt-get install tcpdump
sudo tcpdump -n -i eth0 -c 100

I currently don't see anything wrong with the odroid
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Fri Aug 11, 2017 2:26 am

Here is the output:
Code: Select all
13:21:28.184844 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:28.934824 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:29.684925 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:30.403626 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:30.657638 IP 10.38.0.201.58168 > 239.255.255.250.1900: UDP, length 133
13:21:30.724997 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:31.189124 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:33.403867 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:33.699813 IP 10.38.0.201.58168 > 239.255.255.250.1900: UDP, length 133
13:21:33.869772 IP6 fe80::354a:cde9:5ef6:52f6.546 > ff02::1:2.547: dhcp6 solicit
13:21:34.565521 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:36.189227 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:36.404285 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:36.700427 IP 10.38.0.201.58168 > 239.255.255.250.1900: UDP, length 133
13:21:39.706021 IP 10.38.0.201.58168 > 239.255.255.250.1900: UDP, length 133
13:21:40.026748 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 264
13:21:40.130164 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 273
13:21:40.234165 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 336
13:21:40.338325 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 328
13:21:40.405961 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:40.442421 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 273
13:21:40.546177 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 312
13:21:40.650366 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 344
13:21:40.757968 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 273
13:21:40.862146 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 332
13:21:40.966309 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 326
13:21:41.070435 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 273
13:21:41.174157 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 328
13:21:41.214230 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:41.278330 IP 10.38.0.200.55783 > 239.255.255.250.1900: UDP, length 338
13:21:41.410087 ARP, Request who-has 10.38.0.204 tell 10.38.0.201, length 46
13:21:42.219831 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 129
13:21:42.221234 IP 10.38.0.204 > 239.255.255.250: igmp v2 report 239.255.255.250
13:21:42.221244 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 129
13:21:42.228349 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 129
13:21:42.229892 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 129
13:21:42.233154 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 129
13:21:42.236423 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 127
13:21:42.239094 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 127
13:21:42.239972 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 127
13:21:42.240720 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 127
13:21:42.240729 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 127
13:21:42.242225 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 124
13:21:42.242235 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 124
13:21:42.243147 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 124
13:21:42.244016 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 124
13:21:42.244025 IP 10.38.0.204.3942 > 239.255.255.250.1900: UDP, length 124
13:21:42.433090 IP 10.38.0.204 > 224.0.0.251: igmp v2 report 224.0.0.251
13:21:42.434148 IP 10.38.0.204.5353 > 224.0.0.251.5353: 1 [2q] PTR (QU)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QU)? _googlecast.$
13:21:42.436517 ARP, Request who-has 10.38.0.204 tell 10.38.0.202, length 46
13:21:42.584940 IP 10.38.0.204 > 224.0.0.2: igmp leave 224.0.0.251
13:21:42.585536 IP 10.38.0.204 > 224.0.0.251: igmp v2 report 224.0.0.251
13:21:43.406493 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:43.505087 IP 10.38.0.204.5353 > 224.0.0.251.5353: 2 [2q] PTR (QM)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QM)? _googlecast.$
13:21:43.507017 IP 10.38.0.202.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR Chromecast-7db4490d7a50c3af73aa3b4a61feebdb._googlecast._tcp.local. (350)
13:21:44.507786 IP 10.38.0.204.5353 > 224.0.0.251.5353: 3 [2q] PTR (QM)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QM)? _googlecast.$
13:21:44.514828 IP 10.38.0.202.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 PTR Chromecast-7db4490d7a50c3af73aa3b4a61feebdb._googlecast._tcp.local. (350)
13:21:44.996001 IP 10.38.0.204 > 224.0.0.251: igmp v2 report 224.0.0.251
13:21:46.357744 IP 10.38.0.204 > 239.255.255.250: igmp v2 report 239.255.255.250
13:21:48.185332 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:48.341121 IP 10.38.0.204 > 224.0.0.251: igmp v2 report 224.0.0.251
13:21:48.935274 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:49.145343 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 485
13:21:49.145365 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 495
13:21:49.685439 IP 10.38.0.201.137 > 10.38.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:21:49.820333 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 433
13:21:49.820945 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 443
13:21:49.872501 IP6 fe80::354a:cde9:5ef6:52f6.546 > ff02::1:2.547: dhcp6 solicit
13:21:50.408052 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:51.034323 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 497
13:21:51.035981 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 507
13:21:51.146209 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 513
13:21:51.146858 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 523
13:21:51.242238 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:51.378543 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 442
13:21:51.379099 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 452
13:21:51.629441 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 499
13:21:51.630242 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 509
13:21:52.146510 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 485
13:21:52.146981 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 495
13:21:52.821039 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 433
13:21:52.821579 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 443
13:21:53.408263 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:54.041052 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 497
13:21:54.041634 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 507
13:21:54.146732 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 513
13:21:54.147259 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 523
13:21:54.378784 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 442
13:21:54.379241 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 452
13:21:54.630909 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 499
13:21:54.631457 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 509
13:21:54.638583 IP 10.38.0.204 > 239.255.255.250: igmp v2 report 239.255.255.250
13:21:55.146958 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 485
13:21:55.147535 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 495
13:21:55.821005 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 433
13:21:55.821506 IP6 fe80::354a:cde9:5ef6:52f6.1900 > ff02::c.1900: UDP, length 443
13:21:56.197282 ARP, Request who-has 10.38.0.200 tell 10.38.0.201, length 46
13:21:56.408759 IP6 fe80::354a:cde9:5ef6:52f6.58166 > ff02::c.1900: UDP, length 146
13:21:57.078998 IP 10.38.0.201.1900 > 239.255.255.250.1900: UDP, length 497
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Fri Aug 11, 2017 3:53 am

Hmm, I've identified .201 as a samba/windows host, 204 a chromecast and 202 which I'm not sure what it is. They are all making the usual broadcast/multicast traffic, but 201 seems to be making arp requests for .200 a bit too often. Most likely it never receives the replies and thus is isolated.
If 201 is a windows host, can you install wireshark on it, do a similar capture when the network is not running? Also, what is your your router brand? Is .201 connected over wifi? Can you test with .202, .204 unplugged? (Keep only routers, odroid and a wifi client.
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Sat Aug 12, 2017 4:31 pm

201 is my Win7 Laptop, 202 is my Android phone, 204 was Chromecast. All of them connected over wifi. Router I tried is TP Link TL-WR740N.
I will disconnect phone and chromecast, leave laptop connected over wifi and odroid connected with cable to router and check what is going on using WireShark.
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sat Aug 12, 2017 4:35 pm

After you do the capture upload it somewhere so we can have a look. Also, on your windows laptop please run when the problem manifests:
Code: Select all
ipconfig -a
ping 10.38.0.200
arp
route print
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sat Aug 12, 2017 4:40 pm

If you're up to it you could consider a different firmware for your router: https://wiki.openwrt.org/toh/tp-link/tl-wr740n
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Sat Aug 12, 2017 6:41 pm

I followed your guides. In attachment there is wireshark dump and windows command line info. What is worth mentioning:
- I started wireshark capture before I connected Odroid to router. Odroid is connected c.a. 10 seconds after capture started;
- during capture some programs tried to connect to internet from my laptop - instant messager and a program that does some stuff with mysql database - I couldn't stop them so you can filter out some connections
- during capture I tried to visit Google to indicate what is happening - maybe it helps
- I disconnected Odroid from router before capture stopped - google webpage was loaded after that.

- Windows console output is in Polish, sorry :mrgreen:

Hope you can tell me what is happening!
Attachments
odroid_c2.zip
Wireshark and console dumps
(1.16 MiB) Downloaded 13 times
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sat Aug 12, 2017 10:46 pm

I've reviewed only the windows output - I'll look at the capture when I get to a pc.
It seems that the router still responds to pings and I find it strange that .202 and .204 have the same mac address. Any idea who ac-ee-9e-36-68-fe is?
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Sat Aug 12, 2017 11:10 pm

This MAC is my Chromecast. It was supposed to be off byt probably remained in ARP table as I didn't restart my laptop nor cleared ARP table.
I guess that once it got .202 address via DHCP and later .204 as I might have connected odroid earlier and .202 was taken. Laptop is constantly turned on and connected to wifi as it performs some calculations and sends data to mysql database.
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sat Aug 12, 2017 11:38 pm

I see. I looked briefly over the capture and nothing seems out of place - arp works, dns works.

Can you reproduce the issue and capture on the windows host traffic corresponding to
Code: Select all
ping 8.8.8.8
ping www.google.com
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Mon Aug 21, 2017 2:14 am

Sorry for long lack of response, I had no time even for myself.
I did as you suggested:
1. Disconnected all unnecessary devices (mobile, chromecast, odroid - wifi);
2. Pinged both addressess from win7 machine;
3. Connected eth to odroid and pinged again;
4. Disconnected eth from odroid and pinged third time;

Result is on another server as it's size exceeds size limit on forum: https://www.sendspace.com/file/s2rgjg.
Sorry for excessive traffic, my antivir was updating and I couldn't stop that (and had no time to wait till it finishes) but it will show when traffic died and became alive again.

Any idea what is happening, please?

Best wishes
Damian
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Mon Aug 21, 2017 3:57 pm

Ok, I've had a look. The antivirus traffic is actually useful to see normal behavior.
So, everything works pretty much ok until a few seconds before packet 2935 which is an ARP request from the odroid (.201). After this there is some outgoing traffic from your Windows system which remains unreplied, and some late replies (very few) still come from your router. The MAC addresses on these packets look fine. Also, SSDP traffic from your router looks fine. The router still replies to ICMP. DNS queries no longer receive replies (packet 3012), and also outgoing pings are without reply. Then, in packets 3015, 3019 and 3020 the C2 is without an IP address and makes a DHCP request.
Starting from packet 3305 connectivity is restored (there is a reply for DNS).

I'd like, if possible for you to ping 10.38.0.200 from both the Windows PC and the Odroid during the outage period, and maybe ping the Odroid from the Windows PC or viceversa. No need to capture. My guess is that ping will work in the LAN and the problem is with the Internet connection when the Odroid is plugged in. Not sure why, though. Can you connect the Windows PC via Ethernet instead of wifi and redo the tests? I'm not sure if Wifi is isolated when LAN works or if Internet is unreachable.
Also, can you access the router's interface during this outage period? I'm curious if it has any logs, or if there are web tools to check connectivity, uplink status, etc?
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Mon Aug 21, 2017 4:35 pm

Thanks for analysis. I will check everything as soon as I'm back from work. AFAIR I can connect to Odroid via SSH when there is no communication with WAN but I will make sure of that.
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Thu Aug 31, 2017 3:33 am

Partial results:
During outage period I can ping 10.38.0.200 from both devices (Odroid and Win7). I can ping Odroid from Windows and Windows from Odroid. I believe that means that LAN is working correctly. I cannot ping anything "behind" my router though.
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Thu Aug 31, 2017 3:07 pm

Can you extract any logs from your router after the outage period?
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Thu Aug 31, 2017 3:59 pm

With original firmware from TP Link, the only entries in log are infos about dhcp requests. Nothing else.
The main idea behind is that I need to use minimal version of lunux, without graphic desktops etc. Unfortunately minimal image of Ubuntu for Odroid lacks of wlan connectivity and to get it, I need to connect via wire what is impossible...
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Sat Sep 02, 2017 6:05 pm

[UPDATE]
This issue must be related to my TP-Link router rather than Odroid C2. I found my old old old wireless router - apparently everything works - Odroid is connected via eth0, my laptop via WLAN and I can type and send this message. I will try to flash my new router with OpenWRT, maybe it will help.
Right now this threat may be closed - thank you for support @mad_ady!
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sun Sep 03, 2017 3:30 am

Let us know if openwrt fixes the issue. It's strange because the odroid seems to trigger it with some lan packet. I think you said that once the Odroid used wifi it worked correctly.
The only similar thing I've seen was related to upnp on the router. Once upnp ws off it worked. Maybe try with tplink with upnp off.
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby DamianPe » Sun Sep 03, 2017 4:17 pm

You were right! It was UPnP that was enabled on my TP-Link router. After disabling everything works as supposed!
Weird but worth remembering - Odroid and UPnP @ TP-Link don't like each other :)
DamianPe
 
Posts: 27
Joined: Sat Jul 01, 2017 6:34 pm
languages_spoken: english, polish
ODROIDs: C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sun Sep 03, 2017 4:33 pm

Glad it works now! Though I'm not sure how the odroid triggers the problem
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Weird Ethernet behaviour

Unread postby mad_ady » Sun Sep 03, 2017 5:01 pm

This was where I encountered upnp problems originally: http://wiki.wdlxtv.com/Superhub
User avatar
mad_ady
 
Posts: 2870
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2


Return to Hardware and peripherals

Who is online

Users browsing this forum: No registered users and 3 guests