• Content Count

  • Joined

  • Last visited

About ManoftheSea

  • Rank

Recent Profile Visitors

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

  1. StarSurfer, are you trying to set a static IP on the "external" interface (/etc/systemd/network/ or the internal interface (br0)? Will you paste your configuration file(s) in /etc/systemd/network/ ? Additionally, beware the order of the ports. It may be that the "wan" interface is the right port instead of the left one. In your report, it shows lan0 is UP and wan is DOWN.
  2. Wow, that table is a pain and a half to read! The image of the v7 and its description agree, but don't match the order of jumpers in the table. On the other hand, the image of the v5 and its jumpers disagree on which jumper is which, but one of them matches the table. Can you clarify which labeling you're using, and which direction of jumper you're calling "1" or "0"? This link would have me believe that the jumper next to the SATA connecter is toward the edge of the board, while the other two are toward the center - [J11, J3, J10] = [0, 1, 1] to boot from SATA if oriented with the printed labels, and [1, 1, 0] to boot from NOR. , And that "boot from SATA" link has the jumper settings in the 10, 3, 11 orientation, as opposed to the 11, 3, 10 orientation given in the big table of boot modes. How absolutely horrid! In Summary: The ports and interfaces page needs: - Reorganize the v7 table columns to match the order of the jumpers on the v7 board, either 10,11,3 or 3,11,10, but we don't know whether the columns are correct - Fix the callout on the v5 image to J10, J3, J11 - Reverse the labels on the v5 table columns so it's J10, J3, J11, but don't move the columns.
  3. @Shirohige I see, you are correct the U-Boot can be loaded from alternate locations. I learned something. Your links, however, are describing loading Linux from U-Boot, and are not applicable to loading U-Boot itself. This link tells me that a v5 board is unable to load U-Boot from SD card, while a v7 can. It appears neither version can do so from USB.
  4. I assume you have U-Boot running on your board, because you posted what appears to be the console output and it included: "U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 19 2018 - 11:18:51 +0800)" And also that the CPU was running at 1000 and the 1 gig of DDR at 800. I do not understand why you want to "load" the bootloader, and whether you are distinguishing that from "flashing" the bootloader. You are required to have a bootloader on the board itself. The USB flashing directions indicate a FAT-formatted USB drive. You mentioned an unformatted raw SD, and an EXT4 formatted SD, which are both wrong. I would suggest you try a FAT-formatted SD card, and put the flash-image-ddr3-MEM-RAM_CHIPS-CPU_DDR.bin in the FAT-formatted partition. Then, your flash command is bubt flash-image.bin spi mmc
  5. @dasbee - "saturate the ethernet links" but there's only a single gigabit SERDES to the ethernet switch, so any traffic that has to go to the CPU is limited below the 1 Gbps of the ethernet links.
  6. The instructions say: Copy this flash-image-ddr3/ddr4-MEM-RAM_CHIPS-CPU_DDR.bin to your FAT formatted USB key, plug it into USB3.0 port and execute from u-boot prompt: U-Boot gets flashed to the board, it doesn't need to get run each time from the boot media.
  7. When I plug in the microUSB, I get a green light and the serial device exists, but the system doesn't boot. When I plug in the power supply, I get a slightly brighter green light and the system does boot. Don't be fooled!
  8. Let me retract what I thought was a bug, but is actually only a misconfiguration. In /etc/systemd/network/, I had "IPv6AcceptRA=no". To get IPv6 addresses from upstream, I needed yes. After I fixed that, I'm getting prefix-delegation again. I already had the needed /etc/systemd/network/ entry "IPv6PrefixDelegation=dhcpv6". So, just that one complaint about wan being slow to come up to figure out.
  9. Are you trying to connect to the espressoBIN, or from the espressoBIN? The way I read it, it sounds like from, in which case, does your dmesg give any indication that the serial adapter is connected? There may be a module missing from the kernel compile. If the hardware works on another Debian system, you might try comparing between the dmesg on that system - it might tell you the name of the module.
  10. This past weekend, I thought I'd further tune my home network. My goal was to get suricata running and protecting my network. Reminder: Armbian Buster, Kernel 4.19.56 Suricata was installed by package, along with oinkmaster-suricata. The "emerging" ruleset was installed according to that package, just a run of "suricata-oinkmaster-updater". The Suricata default installation does NOT appear to work on the espressobin. This default uses AF_PACKET to, as I understand it, listen to packets coming in on eth0 and going out on "any other interface". Well, we only have eth0 on EspressoBIN. So I added a rule on the firewall using nft. Note that my firewall table is named "filter", and the added chain is named "IPS". The system's firewall is in a chain called "firewall" at priority 0, not shown here, so suricata should only process packets that would otherwise be allowed by static rules. nft add chain inet filter IPS { type filter hook forward priority 10\; policy accept\;} nft add rule inet filter IPS queue num 2 - 3 fanout,bypass This rule sends packets to queues 2 and 3, which should allow tuning suricata to run on both processors and share the work. "bypass", at the end, means that if suricata fails, it fails open, such that the network still works but without protection. The default install of suricata selects the af-packet mode of operation in the suricata.service file. That is edited with "systemctl edit suricata.service", which will end up putting a /etc/systemd/system/suricata.service.d/override.conf file in place: [Service] ExecStart= ExecStart=/usr/bin/suricata -D -q 2 -q 3 -c /etc/suricata/suricata.yaml --pidfile /var/run/ The first line clears the ExecStart from the base file, and the second has "-q 2 -q 3" to tell suricata to listen to the NFQUEUEs as numbered in the nft rule. Test the setup by watching the /var/log/suricata/fast.log and running `curl -A "BlackSun"` - there should be an ALERT as defined in the emerging user agents rules. Beware that trying against google will go over HTTPS, and therefore the IPS can't detect the content of the traffic. Hopefully this is of use to someone.
  11. I recently, yesterday, updated u-boot to 800-800. I did a dist-upgrade to buster. I've got kernel 4.19.56. I'm using espressobin as a firewall for my home network, connected to comcast (where I used to have ipv6 addresses). systemd reports version 241. This is part status-report, documentation for others, and questions. Used to have ipv6 addresses - So before the dist-upgrade and kernel upgrade, I was on .20 in Jessie. And systemd-networkd was giving me prefix delegation such that my home net had public IPv6. Now, systemd is unable to complete the transaction. It just repeats this block: [edit] I had it misconfigured. Network startup - When the board boots, it seems the wan interface is slow. The first time systemd-networkd tries to configure the wan interface, it gives an error, saying "Network is down". This is easy enough to fix, I just log into the box after any boot and send a `ip link set wan up`, and it works from there. Again with networkd, the bridge interface seems to try to configure too early. See below, "could not bring up interface: invalid argument". This one, however, resolves itself when the lan interface gets set up, as it detects the carrier and goes back to set up the bridge again. So this one's not so bad. orkd[299]: No virtualization found in /proc/device-tree/* orkd[299]: UML virtualization not found in /proc/cpuinfo. orkd[299]: This platform does not support /proc/sysinfo orkd[299]: Found VM virtualization none orkd[299]: lo: Unmanaged orkd[299]: wan: Could not bring up interface: Network is down orkd[299]: lan0: Joined netdev orkd[299]: lan0: Bringing link up orkd[299]: lan1: Joined netdev orkd[299]: lan1: Bringing link up orkd[299]: eth0: Flags change: +UP +LOWER_UP +RUNNING orkd[299]: LLDP: Started LLDP client orkd[299]: eth0: Started LLDP. orkd[299]: eth0: Gained carrier orkd[299]: eth0: Configured ... orkd[299]: br0: udev initialized link orkd[299]: br0: Link state is up-to-date orkd[299]: br0: found matching network '/etc/systemd/network/' orkd[299]: br0: Setting address genmode for link orkd[299]: br0: Bringing link up orkd[299]: br0: Flags change: +UP orkd[299]: br0: Could not bring up interface: Invalid argument orkd[299]: Got inotify event on bus bus-api-network. orkd[299]: Added inotify watch for /run on bus bus-api-network: 2 orkd[299]: Added inotify watch for /run/dbus on bus bus-api-network: -1 orkd[299]: lan0: Flags change: +LOWER_UP +RUNNING orkd[299]: lan0: Gained carrier I found a systemd bug report 12784 that describes similar behavior to what I'm seeing, with Debian sid, kernel 5.2, and systemd 241. It's very recent, so maybe it's already fixed and just needs to propagate? NFTables and network devices - I have an nftable rule that makes use of "iif" (input interface), which supposedly uses the network interface index rather than its name. Which means, if "wan" doesn't exist when nftables.service gets started, then the ruleset fails. That's what I'm seeing. I corrected to "iifname", which does a string compare per packet. That seems wrong. Does anyone have a suggestion for how to order nftables rules for after a given interface is created, but before it's brought up? Maybe a oneshot service that's "after" udev but "before" systemd-networkd? And while I'm on nftables, my ruleset has a "counter". But "nft list counters" doesn't show it, nor getting more specific into "nft list counters table inet filter". When I attempted to name the counter in the ruleset, nft complained about a missing file/directory. I vaguely guess that there's a module missing, but I don't know how to debug that further, and it's not important enough that I'll spend the time, unless someone else would benefit too. But my final state, after a manual process each post-reboot, is that I have a capable, functional linux box as my network firewall. And that's pretty cool.
  12. I had hoped the information might be useful for bisecting which kernel update might be responsible. Is the source of the problem known and fixed, or is the fix being referenced only disabling the 5.85 release? Is it useful for me to search for the older nightlies and narrow it down?
  13. @barish, I was recently trying to debug a similar thing. Do you have "verbosity=1" in /boot/armbianEnv.txt? If so, you're telling the kernel not to log. I set mine to 7 based on a very poor understanding of things I read, and it gives me more log. If you already knew this, then maybe my message will help someone else sometime.
  14. I'm perhaps a little late in contributing to this thread, but after a power outage caused a reboot of mine, I was getting nothing in kernel log just after systemd started in kernel .40. I tried reverting kernel packages, and had failures with linux-image-next-mvebu64_5.83.190502_arm64.deb and linux-image-next-mvebu64_5.84.190508_arm64.deb, but success with .34 (that is, armbian 78.190409) No panic message, just a stop of logging to serial. This weekend, I will try the latest next again and capture the log, maybe someone might find it useful.
  15. I would suggest you look in /etc/systemd/network, at the 10-lan[01].network and files In them, apply a declaration to set the MAC address in the [link] section [Match] Name=lan0 [Link] MACAddress=0011.2233.4455