Jump to content

Gord_W

Members
  • Posts

    18
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I too thought that it was important to file bug reports when things aren't working. Open source is always a sort of beta test and one way people with less skills than developers could contribute is identifying problems, providing details, answering questions and testing solutions. No one is "demanding" anything gets fixed - this is open source. It is important, though, that known problems are identified and confirmed by other people so other users that run into the same problem in the future will know and can act accordingly.
  2. As I said earlier this month, I had the same problem with NanoPi Neo.
  3. Thanks for the workaround. I've tried out DietPi and it doesn't have the problem of changing MAC address. I'm not sure if their image is built on Armbian or directly on Debian for NanoPi Neo H3, but anyway is seems to be light and works.
  4. Hi, I'm also using a nanopi neo and getting a new MAC address on every reboot. I used a fresh install of Buster today (Dec. 1) and this has the problem. I also changed to the nightly build Armbian 21.02.0-trunk.5 Buster with Linux 5.9.11-sunxi and that too has the same problem. Gord_W
  5. Thanks for the feedback Igor. I was going to give these boards another try with the current version hoping that it has been fixed, but it looks like it is not the case. I don't have any problem with the rPi so have been using that for my application, but I bought the NanoPi Neos for it. Any suggestion on what can be done? Gord_W
  6. I've gone back to using a rPi on this project. No problems with the rPi like I have with the NanoPi Neo. My conclusion is that it is an ethernet driver problem with NanoPi Neo. Gord_W
  7. 1) One thing that I have found that is interesting is that whenever I start a program (python script, stress) on the NanoPi while the ethernet link was working, the ethernet link would go down and then come back up. This seems to indicate that it is NanoPi problem (software/hardware) and not a camera/wiring/power problem. I boosted the min clock speed to 816MHz (max at default 912MHz) to see if that might help, but no effect. Governor is interactive. 2) @arox I tried disabling link negotiation and it had no effect. Gord_W
  8. I don't know why you are jumping to the conclusion that it is a hardware problem. I'm not blaming anything so cool your jets. You will note that I said that the camera was directly connected to the camera so there is no switch or anything else in between. The cameras, cables, etc. have all been swapped out. It could be a hardware problem with the Nanopi or camera. I've used the cameras in the past with rPi2 and 3 and not had this problem. It could be a software problem in the way that I'm setting the iptables up. I don't know so was asking for suggestions. @arox I'll look at disabling link negotiation. Thanks. Gord_W
  9. Blars, I had killed and removed the networkmanager earlier and it did have any effect. Still having the interface go down and up. I wonder why 1 second increments are happening between the ups and downs. Gord_W
  10. Using Nanopi neo. Linux Lap 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux I've tried both the Jessie and Ubuntu versions on the site and tried changing the the kernels to 4.x with the next and dev versions. I get similar results in each. Tried to upload diagnostics but got server error I have an IP camera connected directly to the ethernet port with static IP on both the camera and the port. I ssh to the nanopi via wifi. The wifi port is forwarded to the ethernet connection so I can get images from the camera. The ethernet connection seems to drop at random intervals but the time that it down/up are exactly 1 second multiples. I've got a couple of nanopi and a couple of the same cameras and tried them in different combos with the same results. Tried different power supplies. I haven't found a similar problem on the internet. Must be something that I'm doing .... This is a section of the dmesg log [Jan16 16:06] PHY: gmac0-0:00 - Link is Down [ +2.000012] PHY: gmac0-0:00 - Link is Up - 100/Full [ +19.999982] PHY: gmac0-0:00 - Link is Down [ +1.999998] PHY: gmac0-0:00 - Link is Up - 100/Full [ +5.999988] PHY: gmac0-0:00 - Link is Down [ +1.000022] PHY: gmac0-0:00 - Link is Up - 100/Full [Jan16 16:33] PHY: gmac0-0:00 - Link is Down [ +1.999999] PHY: gmac0-0:00 - Link is Up - 100/Full [ +2.000010] PHY: gmac0-0:00 - Link is Down [ +2.999958] PHY: gmac0-0:00 - Link is Up - 100/Full [ +14.000039] PHY: gmac0-0:00 - Link is Down [ +1.000001] PHY: gmac0-0:00 - Link is Up - 100/Full [Jan16 17:00] PHY: gmac0-0:00 - Link is Down [ +0.999890] PHY: gmac0-0:00 - Link is Up - 100/Full [ +12.000095] PHY: gmac0-0:00 - Link is Down [ +1.000006] PHY: gmac0-0:00 - Link is Up - 100/Full [ +23.999968] PHY: gmac0-0:00 - Link is Down [ +1.000033] PHY: gmac0-0:00 - Link is Up - 100/Full [Jan16 17:03] PHY: gmac0-0:00 - Link is Down [ +2.000002] PHY: gmac0-0:00 - Link is Up - 100/Full [Jan16 17:05] PHY: gmac0-0:00 - Link is Down [ +0.999836] PHY: gmac0-0:00 - Link is Up - 100/Full [Jan16 17:10] PHY: gmac0-0:00 - Link is Down [ +0.999994] PHY: gmac0-0:00 - Link is Up - 100/Full [ +28.000053] PHY: gmac0-0:00 - Link is Down [ +1.999997] PHY: gmac0-0:00 - Link is Up - 100/Full There are some dropped wifi packets but no ethernet. root@Lap:~# ifconfig eth0 Link encap:Ethernet HWaddr 46:bf:e5:d8:89:bf inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::44bf:e5ff:fed8:89bf/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4482690 errors:0 dropped:0 overruns:0 frame:0 TX packets:3301078 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2301875353 (2.1 GiB) TX bytes:193423473 (184.4 MiB) Interrupt:114 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:16436 Metric:1 RX packets:200 errors:0 dropped:0 overruns:0 frame:0 TX packets:200 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16656 (16.2 KiB) TX bytes:16656 (16.2 KiB) wlan0 Link encap:Ethernet HWaddr 00:0b:81:81:58:42 inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20b:81ff:fe81:5842/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3315272 errors:0 dropped:11889 overruns:0 frame:0 TX packets:4502840 errors:0 dropped:3 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:335517701 (319.9 MiB) TX bytes:2434428264 (2.2 GiB) Could it be that I messed up iptables? The images are coming through. root@Lap:~# iptables -L -vt nat Chain PREROUTING (policy ACCEPT 241 packets, 11574 bytes) pkts bytes target prot opt in out source destination 37210 2233K DNAT tcp -- wlan0 any anywhere anywhere tcp dpt:5006 to:10.0.0.100:80 Chain INPUT (policy ACCEPT 15 packets, 3372 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 114 packets, 8444 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 114 packets, 8444 bytes) pkts bytes target prot opt in out source destination 37210 2233K SNAT tcp -- any eth0 anywhere anywhere to:10.0.0.1 I can't see anything which is causing it. Suggestions? Regards, Gord_W
  11. Sorry for the slow reply, I just saw it. I don't know if this is any use to you still, but here it is. root@Lap:~# armbianmonitor -u System diagnosis information will now be uploaded to http://sprunge.us/SMFU Please post the URL in the forum where you've been asked for. Since I have removed NetworkManager and added ethernet and wifi details in /etc/network/interface, I've had no problems with wifi. Gord_W
  12. Follow up. After purging NetworkManager (that takes a huge amount of other stuff too) and entering wlan0 and eth0 in /etc/network/interface, it has been up for a few days without the wifi failing. Gord_W
  13. Using NanoPi Neo with Linux Lap 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l armv7l armv7l GNU/Linux with current Armbian updated. Headless server. I've had the same problem. The wireless stops working (I think only partially) so I can't ping or ssh the unit. Interestingly, when I try and ping the wifi dongle LED flashes as I would expect for a ping and the AP wifi light also flashes at the same time. I'm using wifi to connect to the LAN and internet with dhcp (192.168.1.x) and have the ethernet unplugged but with a static IP set to a different network (10.0.0.x). If I turn off the AP wireless, the LED on the wifi dongle goes out and when I start the AP wireless it comes back on. The AP logs don't show the NanoPi asking for an IP though. Gord_W Dec 15 07:06:25 Lap dhclient[819]: DHCPREQUEST of 192.168.1.17 on wlan0 to 192.168.1.1 port 67 (xid=0x49d4e22) Dec 15 07:06:25 Lap dhclient[819]: DHCPACK of 192.168.1.17 from 192.168.1.1 Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7334] address 192.168.1.17 Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7336] plen 24 (255.255.255.0) Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7338] gateway 192.168.1.1 Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7339] server identifier 192.168.1.1 Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7339] lease time 86400 Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7341] nameserver '192.168.1.1' Dec 15 07:06:25 Lap NetworkManager[434]: <info> [1513339585.7342] dhcp4 (wlan0): state changed bound -> bound Dec 15 07:06:25 Lap NetworkManager[434]: <error> [1513339585.7368] platform-linux: do-add-ip4-address[4: 192.168.1.17/24]: failure 17 (File exists) <<<<<<<<<<<<<<<<<<< Problem lines Dec 15 07:06:25 Lap NetworkManager[434]: <error> [1513339585.7385] platform-linux: do-add-ip4-route[4: 0.0.0.0/0 600]: failure 3 (No such process) <<<<<<<<<<<<<<<<<<< Problem lines Dec 15 07:06:25 Lap dbus[401]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Dec 15 07:06:25 Lap NetworkManager[434]: <warn> [1513339585.7387] default-route: failed to add default route 0.0.0.0/0 via 192.168.1.1 dev 4 metric 600 mss 0 src user with effective metric 600 Dec 15 07:06:25 Lap dhclient[819]: bound to 192.168.1.17 -- renewal in 33647 seconds. Dec 15 07:06:25 Lap systemd[1]: Starting Network Manager Script Dispatcher Service... Dec 15 07:06:26 Lap dbus[401]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Dec 15 07:06:26 Lap systemd[1]: Started Network Manager Script Dispatcher Service. Dec 15 07:06:26 Lap nm-dispatcher[9137]: req:1 'dhcp4-change' [wlan0]: new request (1 scripts) Dec 15 07:06:26 Lap nm-dispatcher[9137]: req:1 'dhcp4-change' [wlan0]: start running ordered scripts...
  14. Hi, From a quick search of the forum this appears to be happening across different CPUs so I am posting here rather in the H3 forum. Using the current updated legacy version. ARMBIAN 5.36 Ubuntu 16.04.3 LTS 3.4.113-sun8i /var/log/syslog gets repeated messages due to xconsole not being installed. Ref: https://devcentral.nasqueron.org/T806 https://forum.odroid.com/viewtopic.php?f=136&t=21897 The solution is to comment out the last few lines in /etc/rsyslog.d/50-default.conf nano /etc/rsyslog.d/50-default.conf so it looks like ... # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # #daemon.*;mail.*;\ # news.err;\ # *.=debug;*.=info;\ # *.=notice;*.=warn |/dev/xconsole Restart the logging: service rsyslog restart Now there are no more messages every couple minutes filling up the logs. Hope that helps someone else. Regards, Gord_W Dec 12 12:23:28 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:24:28 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:25:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:26:01 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:27:10 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:28:10 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:35:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:36:01 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:38:12 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:39:12 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:39:30 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:40:30 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:40:33 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:41:33 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:43:37 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:44:37 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:45:02 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:46:02 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:55:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:56:01 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:56:17 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 12:57:47 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 12:59:44 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:01:14 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:01:37 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:03:07 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:05:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:06:31 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:15:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:16:31 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:17:01 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:18:31 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:19:22 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:20:52 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Dec 12 13:23:37 localhost rsyslogd-2007: action 'action 9' suspended, next retry is Tue Dec 12 13:25:07 2017 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
  15. Hmm, I had a look at the pages you suggested. Would like to help but that is way above my pay grade. Sorry. Gord_W
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines