search

neilbrown / gnubee-tools

Tools for building gnubee firmware - and maybe more.
Other
31 stars 14 forks source link

Newest self build linux+initramfs breaks networking #2

Open ghost opened 6 years ago

ghost commented 6 years ago

(I'm not sure if this is the right place for this, please tell me if I should reopen the issue somewhere else)

with your linux commit 13e903a94c7301ebf8b4b62c3a1b7ad9fa49e16c and gnubee-tools commit 4372644f7c5e74068517d1ab6160097dd322c3cd my gnubee2 is not able to reach other hosts over the network. the same setup works with the image "gnubee-pc1-900-4.4.144.bin" from http://neil.brown.name/gnubee/. in both cases I'm loading the images with tftp.

I'm running debian 9, here are some other infos about the system when booted with the non working kernel: /etc/network/interfaces (/etc/network/interfaces.d is empty):

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0.1
iface eth0.1 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1

auto eth0.2
iface eth0.2 inet dhcp

uname -a

Linux lifeboat 4.4.144 #2 SMP Wed Aug 1 14:21:38 CEST 2018 mips GNU/Linux

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 90:50:5a:55:44:9c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9250:5aff:fe55:449c/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:50:5a:55:44:9c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0.1
       valid_lft forever preferred_lft forever
    inet6 fe80::9250:5aff:fe55:449c/64 scope link 
       valid_lft forever preferred_lft forever
4: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:50:5a:55:44:9c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9250:5aff:fe55:449c/64 scope link 
       valid_lft forever preferred_lft forever

lsmod

Module                  Size  Used by
btrfs                 866551  0
xor                     5595  1 btrfs
raid6_pq               86576  1 btrfs
sg                     20480  0
ip_tables              10029  0
x_tables               12516  1 ip_tables
autofs4                20251  0
crc32c_generic          1328  3
ext4                  331914  1
mbcache                 7309  1 ext4
jbd2                   56002  1 ext4
mmc_block              22929  0
mtk_sd                 18400  0
mmc_core               78982  2 mmc_block,mtk_sd
sd_mod                 25120  2
usb_storage            38507  1
xhci_mtk                3824  0
xhci_hcd               83983  1 xhci_mtk
usbcore               121500  3 usb_storage,xhci_hcd,xhci_mtk
usb_common              2349  1 usbcore
nls_base                5296  1 usbcore
ahci                   13248  0
libahci                18315  1 ahci
libata                126110  2 ahci,libahci
scsi_mod               86544  4 sg,usb_storage,libata,sd_mod

ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4015ms
pipe 3

dmesg_not_working.txt

neilbrown commented 6 years ago

This is probably as good a place as any to report problems. I don't see issues posted here very quickly, I see them eventually.... The firmware that does work for you is built with exactly the sources that you say don't work for you, so the mostly likely explanation is that something went wrong in the build process. Are you building on the gnubee or on some other host? In the latter case it needs to ssh over to the gnubee to compile some code and extract some Debian binaries. Maybe provide a log of the build process? And maybe an "ls -lR" of the initramfs directory created during the build.

ghost commented 6 years ago

here's the build log and ls -lR initramfs. the build log shows that swconfig fails to build, I don't know how to fix it, making a fresh clone of gnubee-tools didn't help (even though I have to make a few modifications (use_remote_path.txt))

build.log initramfs_lR.txt use_remote_path.txt (git diff)

vgiralt commented 6 years ago

This line from your use_remote_path.txt path=`$remote 'PATH=/sbin:/usr/sbin:$PATH'` has an issue. You are enclosing the PATH in single quotes ('), which prevent $PATH to be translated, try enclosing them in double quotes (") that do not prevent shell expansion.

Same here: path=`$remote 'PATH=/sbin:/usr/sbin:$PATH'`

ghost commented 5 years ago

without the quotes the PATH variable gets expanded on the local computer, not on the gnubee. I get the same results without the patch too.

vgiralt commented 5 years ago

True! But ... What are you trying to achieve with the two commands? On a second read, invoking ssh to the GnuBee with no real command except a variable assignment and trying to get a result into another, makes no sense to me.

ghost commented 5 years ago

the full command is $remote 'PATH=/sbin:/usr/sbin:$PATH' which $b 2> /dev/null. it returns the path of the to the binary in $b, preferring statically linked binaries

vgiralt commented 5 years ago

That does make sense. My excuses, somehow the rest of the command escaped my view.