| View previous topic :: View next topic |
| Author |
Message |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
 Posted: Wed Dec 06, 2017 9:53 am Post subject: |
 |
|
takhisis_astrafall,
Can you use the chroot if you do not use your wrapper?
I use a setup script
| Code: | $ cat /usr/aarch64-unknown-linux-gnu/prep_chroot
#!/bin/bash
# run this script to prepare the arm64 chroot
# for QEMU building
# start the binfmt service on the host
# ignore the error if its already running
/etc/init.d/binfmt start
# tell the kernel about aarch64 - the above service should do it
# but it seems not to, sometimes.
echo ':aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-aarch64:' > /proc/sys/fs/binfmt_misc/register
cd /usr/aarch64-unknown-linux-gnu/
mount --bind /usr/portage usr/portage
mount --bind /usr/portage/distfiles var/cache/distfiles
# not /usr/portage/packages as they are for the host!
mount --bind /proc proc
mount --bind /sys sys
mount --bind /dev dev
mount --bind /dev/pts dev/pts
# must be after the bind mount of dev
mount tmpfs -t tmpfs -o rw,nosuid,nodev,noexec dev/shm
# don't actually do the chroot
|
followed by | Code: | chroot /usr/aarch64-unknown-linux-gnu/ /bin/bash --login
source /etc/profile
export PS1="aarch64 $PS1" |
I don't use a wrapper. There is a write up on the wiki.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
 |
takhisis_astrafall
Tux's lil' helper
Joined: 04 Apr 2004
Posts: 127
Location: rennes
|
| Posted: Wed Dec 06, 2017 12:55 pm Post subject: |
|
|
Ah !
I was confused by the way I used it on rpi1.
I tested without the wrapper, and it's working !
Thank you ! |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Dec 08, 2017 2:52 pm Post subject: |
|
|
orion777,
apologies for the delay in replying, I have been travelling.
Probably easiest is to remove the Huawei E3372h devices' provided eth interface names from NetworkManager's set as discussed, then configure /etc/dhcpccd.conf to have an "allowinterfaces" stanza that matches them (e.g., if they show up as eth1 eth2 etc. then you could add "allowinterfaces eth1,eth2" to that file). Then start dhcpcd ("/etc/init.d/dhcpcd start"). Hopefully that'll be enough to get an IP address from each of the E3372h's internal DHCP servers (without any further configuration). If it works, you can "rc-update add dhcpcd default" to have the service run at startup.
PS from this E3372h page, it appears you may need to emerge sys-apps/usb_modeswtich also?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sat Dec 09, 2017 8:19 am Post subject: |
|
|
| Sakaki wrote: | orion777,
Probably easiest is to remove the Huawei E3372h devices' provided eth interface names from NetworkManager's set as discussed, then configure /etc/dhcpccd.conf to have an "allowinterfaces" stanza that matches them (e.g., if they show up as eth1 eth2 etc. then you could add "allowinterfaces eth1,eth2" to that file). Then start dhcpcd ("/etc/init.d/dhcpcd start"). Hopefully that'll be enough to get an IP address from each of the E3372h's internal DHCP servers (without any further configuration). If it works, you can "rc-update add dhcpcd default" to have the service run at startup. |
But the dhclient will also starts as a child of NetworkManager. I suppose that two running DHCP clients is not good idea. So maybe I have to reemegre NetworkManager to support dhcpcd and that dhclient should be removed from the NetworkManager config?
| Sakaki wrote: | | PS from this E3372h page, it appears you may need to emerge sys-apps/usb_modeswtich also? |
Yes, of course.
Just to know: Huawei 3372(h) can be running in two modes:
1) Hi-Link - its SW number will starts from 22.*. In this mode it runs as card reader + CD-ROM containing drivers for the windows and linux. It can be switched in "operational" by installing usb_modeswitch (gentoo example is here, but all other linuxes are using same technique ttps://wiki.gentoo.org/wiki/USB_mobile_broadband_modem ). The switching is done automatically; no manual config is required if usb_modeswitch is installed. Dongle switching is done every time when the 3372 is initialized and it can be seen by running dmesg command. When switched, it provide NDIS network card + cardreader. NDIS card will obtain its eth* name and its IP can be assigned by any dhcp client. Further modem config is done thru web by accessing gateway IP (192.168.8.1 by default) and a modem will runs its internal NAT server.
2) Stick - its SW number is starting from 21.* It also has initial state with CD-ROM + cardreader. It should be switched to operating mode by running usb_modeswitch, which was discussed above. In this mode it will NOT run any internal NATand WEB servers. The PPP connection initialization should be done manually (you can use scripts) or by running ConnectManager (huawei software). Its maximum speed will be limited by 54Mbps compared with 150Mbps in Hi-Link.
But the benefits are:
2.1) lower delays (NAT server in Hi-Link mode typically adds 20 ms)
2.2) lower dongle load (its temperature and power consumption will be reduced)
2.3) possibility to control its mode and to get network info directly from the terminal by using AT^ commands by accessing virtual serial PC UI interface (more about ports names depending on configuration can be found here http://gentoo.valek.me/2014/08/lte-huawei-e3272-linux.html if interesting reader is so interesting, to be ready to use translator from russian)
2.4) only in stick mode initial configuration (cd-rom + card reader) can be disabled, hence no usb_modeswitch will be required (a good solution if you want to use it in conjunction with routers). Just run at^setport="ff;10,12,16,a2" , where FF is to disable initial CD-ROM, while others parameters are used to specify interfaces.
The interesting reader may find a lot of up-to-date SW 21 or 22, now to fix TTL, custom webinterfaced, hot to unsign dongle from operator by running single (and free) AT command, etc... for the huawei3372h here http://4pda.ru/forum/lofiversion/index.php?t582284.html . It is not advertising, just an advice, as most of other resources are empty or outdated; a lot of forum pages, mostly in russian, but questions in english are also acceptable.
I leave my experience here just for the reference, maybe someone access it thru google and will find it useful. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sat Dec 09, 2017 5:31 pm Post subject: |
|
|
| orion777 wrote: | | But the dhclient will also starts as a child of NetworkManager. I suppose that two running DHCP clients is not good idea. So maybe I have to reemegre NetworkManager to support dhcpcd and that dhclient should be removed from the NetworkManager config? |
It shouldn't matter unless both try servicing the same interface (which the setup described previously should avoid). In fact if you make NM use dhcpcd and then instruct NM to ignore particular interfaces, it may cause the OpenRC-based dhcpcd service to ignore those interfaces also (the contents of /etc/dhcpcd.conf notwithstanding). Not sure, you'd have to try it to see.
However, I think using a slaved dhclient for NetworkManager (dhclient -dhcpcd USE flags), and a 'service' dhcpcd for all the other (NM-unmanaged interfaces), with an appropriate allowinterfaces stanza in /etc/dhcpcd.conf, should work.
If you get a chance to try one or both of these configs I'd be interested to hear the results.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sun Dec 10, 2017 6:56 pm Post subject: |
|
|
First of all, I want to highlight that NetworkManager runs dhclien for every added eth. However, connecting second huawei does NOT cause additional dhclient to run.
Now I'm trying to set both huawei unmanaged in the NetworkManager.
| Code: | pi64 /etc/NetworkManager/conf.d # cat 50-hostname-mode-none.conf
# prevent DHCP setting the hostname, as this can cause .Xauthority problems
# see e.g. https://bbs.archlinux.org/viewtopic.php?id=202710
[main]
hostname-mode=none
plugins=ifupdown,keyfile
[ifupdown]
unmanaged-devices=mac:0c:5b:8f:27:9a:64 |
However, after reboot, both huawei are still listed in ifconfig and additional dhclient is running when first huawei is inserted. Probably, I'm doing something wrong in /etc/NetworkManager/conf.d .. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sun Dec 10, 2017 7:46 pm Post subject: |
|
|
orion777,
If you stop NetworkManager (/etc/init.d/NetworkManager stop) and also stop any running dhclient instance, then start dhcpcd, does that setup an address for each of your Huawei adaptors?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Mon Dec 11, 2017 9:18 pm Post subject: |
|
|
All the following experiments has been done thru ssh under root.
Experiment #1:
Compiled kernel by bcmrpi3_defconfig +
+
> CPU Power Management > CPU Frequency scaling --- Default CPUFreq governor (powersave) ---> Ondemand
+
Device drivers ---> [*] USB support ---> <*> USB Serial Converter support ---> efewfw<*> USB driver for GSM and CDMA modems
Inserting first huawei; additional dhclient becomes running; ip is assigned; both eth0 (build-in ethernet) and eth1 can be used by ping.
Inserting second huawei; no additional dhclient, no ip for the eth2; both eth0 and eth1 are still accessible.
Experiment #2:
Kernel as specified above.
dhcpcd in autostart by rc.
Inserting first huawei; additional dhclient becomes running; ip is assigned; both eth0 (build-in ethernet) and eth1 can be used by ping.
Inserting second huawei,
- here we have two options: if ping was running on eth1, than inserted eth2 gets 169.254.160.* after dhcp timeout and, of-course, eth2 is not working; no additional dhclients
- if we inserting second huawei without accessing first one, than eth2 gets right ip, however there are no additional dhclient (hence it gets it thru dhcpcd). BUT: pinging thru eth1 or eth2 is not working (no answer) and sometimes PI64 can freeze, SSH becomes aborted and new one cannot be initiated; sometimes ping is just not working on eth1 and eth2, but still works on eth0.
Experiment #3:
Kernel as specified above.
dhcpcd in autostart by rc.
pi64 ~ # /etc/init.d/NetworkManager stop
* Unmounting network filesystems ... [ ok ]
* Stopping NetworkManager ... [ ok ]
pi64 ~ # ps -A -H | grep dhclient
1811 ? 00:00:00 dhclient
pi64 ~ # kill -9 1811
pi64 ~ # ps -A -H | grep dhclient
pi64 ~ # ps -A -H | grep dhcpcd
2067 ? 00:00:00 dhcpcd
Inserting first huawei - it gets right dhcp obtained IP.
Inserting second huawei - it gets 169.254.160.* after dhcp timeout.
Try to disconnect one of them and PI becomes very slow..
| Code: | top - 21:08:32 up 6 min, 1 user, load average: 1.87, 0.94, 0.37
Tasks: 139 total, 1 running, 138 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.3 sy, 0.0 ni, 63.3 id, 36.4 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 986352 total, 849032 free, 40604 used, 96716 buff/cache
KiB Swap: 1048572 total, 1048572 free, 0 used. 931424 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2743 root 20 0 5332 2520 2204 R 1.6 0.3 0:00.45 top
2742 root 20 0 0 0 0 S 0.3 0.0 0:00.01 kworker/1:1
1 root 20 0 1868 1316 1212 S 0.0 0.1 0:00.69 init |
Here I must restart OR ifconfig eth1 down and ifconfig eth2 down and than everything becomes Ok.
Please pay attention, that I'm always receive failures of setting new cpu frequency if huawei is inserted.
The example below shows the time, when both huawey are down by ifconfig. There are no new failed msgs when no huaweys are inserted.
| Code: | [ 487.495757] bcm2835-cpufreq:bcm2835_cpufreq_set_clock:84: Failed to set clock: 1200000 (-12)
[ 487.495770] bcm2835-cpufreq:bcm2835_cpufreq_driver_target_index:183: Error occurred setting a new frequency (1200000)
[ 487.495780] cpufreq: __target_index: Failed to change cpu frequency: -22
[ 492.495763] bcm2835-cpufreq:bcm2835_cpufreq_set_clock:84: Failed to set clock: 1200000 (-12)
[ 492.495777] bcm2835-cpufreq:bcm2835_cpufreq_driver_target_index:183: Error occurred setting a new frequency (1200000)
[ 492.495787] cpufreq: __target_index: Failed to change cpu frequency: -22
[ 496.232909] usb 1-1.5: USB disconnect, device number 9
[ 496.233159] cdc_ether 1-1.5:1.0 eth2: unregister 'cdc_ether' usb-3f980000.usb-1.5, CDC Ethernet Device
[ 496.253855] scsi 1:0:0:0: rejecting I/O to offline device
[ 496.253876] scsi 1:0:0:0: killing request
[ 496.311027] udevd[2692]: inotify_add_watch(7, /dev/sdb, 10) failed: No such file or directory
[ 509.364805] usb 1-1.2: USB disconnect, device number 5
[ 509.365047] cdc_ether 1-1.2:1.0 eth1: unregister 'cdc_ether' usb-3f980000.usb-1.2, CDC Ethernet Device
|
I was trying to put multimeter to USB connector legs and it shows 5.10 .. 5.15; power led is also stable and not blinking.. USB sockets, Ethernet socket and audio socket are contaminated by colophony, so I will wash them out in a close time..
Also, may be I have to disable power management in the kernel config.. |
|
| Back to top |
|
|
hrothgar13
n00b
Joined: 12 Nov 2017
Posts: 1
|
| Posted: Fri Dec 15, 2017 3:18 am Post subject: Initramfs switch_root hangs |
|
|
Hi,
First of all,
@sakaki Great job on the RPi3 64-bit image, after playing around with virtualizations, cross-compiling and more for the RPi3 I really appreciate the work that has gone into this. It was a joy to behold.
Secondly, a curiosity.
I have been experimenting with setting up an encrypted RPi3 which is decrypted by logging via a dropbear ssh on an initramfs. I followed the custom initramfs guide to set this up.
https://wiki.gentoo.org/wiki/Custom_Initramfs
Unfortunately, the last portion of my initramfs init seems to hang.
Specifically.
| Code: |
# Clean up.
umount /proc
umount /sys
umount /dev
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
|
I managed to get the RPi3 to boot from the encrypted partition by changing this to.
| Code: |
# Clean up.
mount --move /proc /mnt/root/proc
mount --move /sys /mnt/root/sys
mount --move /dev /mnt/root/dev
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
|
Frostschutz on wiki.gentoo.org suggested that the reason for the umount is to start init in a clean state. Which makes me curious.. is the OpenRC on RPi-3 different?
Should I be moving the mounts of /proc /sys /dev , or umounting them on the RPi3 ?
If OpenRC is meant to be mounting these systems itself, but does not, what might be preventing this ? |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sat Dec 16, 2017 2:34 pm Post subject: Re: Initramfs switch_root hangs |
|
|
hrothgar13,
| hrothgar13 wrote: | | @sakaki Great job on the RPi3 64-bit image, after playing around with virtualizations, cross-compiling and more for the RPi3 I really appreciate the work that has gone into this. It was a joy to behold. |
Thanks, glad you found it useful ^-^
| hrothgar13 wrote: | I managed to get the RPi3 to boot from the encrypted partition by changing this to.
| Code: |
# Clean up.
mount --move /proc /mnt/root/proc
mount --move /sys /mnt/root/sys
mount --move /dev /mnt/root/dev
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
|
Frostschutz on wiki.gentoo.org suggested that the reason for the umount is to start init in a clean state. Which makes me curious.. is the OpenRC on RPi-3 different?
Should I be moving the mounts of /proc /sys /dev , or umounting them on the RPi3 ?
If OpenRC is meant to be mounting these systems itself, but does not, what might be preventing this ? |
I'm not aware of anything particularly odd in the RPi3's OpenRC setup. FWIW whenever I have done something similar I've usually --move'd proc, sys and dev into the new root too, rather than attempting to unmount them completely. See e.g. Rob Landley's "Programming for Initramfs" (last section on page).
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sat Dec 16, 2017 2:44 pm Post subject: |
|
|
orion777,
what does ifconfig -a show for each of your three experiments (after you have attached the second Huawei)?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sat Dec 30, 2017 9:58 am Post subject: |
|
|
Good Day! I have more or less good news: problem with resolwing IP addresses for two identical Huawei 3372h with identical ether (MAC-address) is partially solved.
dhcpcd must be started automatically (rc-update add /etc/init.d/dhcpcd). Recompiling NetworkManager to support dhcpcd gives no result)
Option #1: first inserted huawei forses NetworkManager to start dhclient, which assigns IP address. Second inserted Huawei gets its IP by means of dhcpcd.
Option #2: NetworkManager can be killed or removed from autostart. Than both huaweis will get iys IPs by means of dhcpcd.
Warning:
1) maximum two network interfaces can get its IP! If eth0 (wired) has been connected, than only first huawei will get its ip, while second will wait until timeout and than gets default like 169.x.x.x. Same occurs if both huaweis were inserted first (both gets its IP via DHCP), but if then you will try to connect wired eth0, than it will gets default 169.x.x.x like after dhcp timeout.
2) CPU Speed on demand fails as soon you insert first huawei (dmesg reports a lot of error to set CPU frequency). If two huaweis are inserted, this messages is repeated very quickly and PI64 starts to break a lot. I'm now working on without CPU freq scaling (it is disabled in kernel config). No failed messages is shown now, rpi on demand fails on boot, CPU is operating slowly (noticeable slowly when you try to emerge something)
3) and of-course user must select different gateway addresses (default is 192.168.8.1) for each huawei by using it web interfaces |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Wed Jan 10, 2018 6:12 pm Post subject: |
|
|
Good evening! I'm trying to install MPTCP ( http://multipath-tcp.org/pmwiki.php/Users/DoItYourself ). Is it possible?
1) cloning into /usr/src/linux/ by git clone --depth=1 git://github.com/multipath-tcp/mptcp.git
2) cd /mptcp
make menuconfig opens tui, but none of options are selected. Tui reports kernel version .config - Linux/arm64 4.9.75, also there are no .config file; . Hence, I've trying to make default .config
3) make distclean
4) make bcmrpi3_defconfigpi64 /usr/src/linux/mptcp # make bcmrpi3_defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
***
*** Can't find default configuration "arch/arm64/configs/bcmrpi3_defconfig"!
***
make[1]: *** [scripts/kconfig/Makefile:112: bcmrpi3_defconfig] Error 1
make: *** [Makefile:541: bcmrpi3_defconfig] Error 2
Seems that I cant' exclude this git, because my existing kernel 4.10 does not have options, that are shown here https://wiki.gentoo.org/wiki/MultiPath_TCP
Maybe it is possible to mix this git extras with existing sources of the 4.10 kernel? As I can't understand what means
Installation
Get sources from mptcp or manually patch the Linux kernel.
So I'm asking for help, because seems that I cant solve this by myself.. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
| Posted: Wed Jan 10, 2018 6:22 pm Post subject: |
|
|
orion777,
Two devices with the same MAC address is broken by design.
MAC address need to be unique.
Its possible to set the MAC address in /etc/conf.d/net but NetworKManager will not use that file.
Not all devices support MAC address changing either.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sat Jan 13, 2018 8:16 am Post subject: |
|
|
NeddySeagoon
Ok, I can work with netifrc, that reads /etc/conf.d/net config, and NetworkManager can be excluded from my setup. (also it is possible to recognize and to work with two huawei dongles simultaneously using NetworkManager, but in this case wired or wireless cands must me disconnected).
The problem is that I'm planning to use gentoo on rpi64 to control remotely piloted car model by means of 3G/4G. However, sometimes cellular data transfer is not stable, maybe there are no sufficient signal strength, etc., so I want to build redundant solution by using two 3G/4G dongles simultaneously.
I was trying network bonding, but it fails because huawei dongles contains NAT servers, so such configuration cannot be bonded https://forums.gentoo.org/viewtopic-p-8168168.html#8168168
So now I wish to try to install MPTCP http://multipath-tcp.org/pmwiki.php/Users/DoItYourself ,because seems that it can do what I want.
The problem is that I cant understand how to manually patch the Linux kernel as specified in this short howto https://wiki.gentoo.org/wiki/MultiPath_TCP |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
| Posted: Sat Jan 13, 2018 12:23 pm Post subject: |
|
|
orion777,
The daily snapshots stopped a while ago. The git page looks like a whole 4.9 kernel.
The command | Code: | | git clone --depth=1 git://github.com/multipath-tcp/mptcp.git |
will fetch the entire kernel into your present working directory.
You build and install it in the normal way. genkernel will want some help as it will not set the options that it knows nothing about.
For this to work over 3G/4G your data paths need to be on separate real carriers, not on separate virtual networks.
Ideally, they will have all their own infrastructure too. Sadly, in the UK, for 4G at least, the carriers had their heads banged together and were forced to share infrastructure.
This means that your redundancy could well be an illusion.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Sun Jan 14, 2018 8:40 pm Post subject: |
|
|
As can be seen here https://wiki.gentoo.org/wiki/Raspberry_Pi_3_64_bit_Install#Fetch.2C_Configure_and_Build_the_Raspberry_Pi_Kernel rpi64 support has been added starting from kernel 4.10.
So, if I wish to use
| Code: | | git clone --depth=1 git://github.com/multipath-tcp/mptcp.git |
from http://multipath-tcp.org/pmwiki.php/Users/DoItYourself , than I will have to use kernel 4.9, so it is necessary to downgrade to rpi32, right?
As I can understand about gentoo, it is NOT possible to use prepared apt-repository http://multipath-tcp.org/pmwiki.php/Users/AptRepository
or rpm-repository http://multipath-tcp.org/pmwiki.php/Users/RPM
Also there is You can also apply one of the patches based on different Linux versions, available http://multipath-tcp.org/patches/
I cant understand what means this patches, but maybe it can solve problem, how to use kernel 4.10 ? But 4.10 exists there! mptcp-v4.10-d9c9f927..> 2017-10-31 22:30 587K
In fact, as I understand, there are only few kernel options are required to run this solution. This options are listed here https://wiki.gentoo.org/wiki/MultiPath_TCP
Or maybe it is possible to combine kernel files from original gentoo and what we have here.. I can't understand :/ |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 12:42 am Post subject: |
|
|
orion777,
There are lots of different kernels floating around the internet.
| Code: | | git checkout rpi-4.10.y |
gets you a kernel with Raspberry Pi patches that are not in the vanilla-sources or gentoo-sources kernels.
They may never be.
rpi-4.9.y kernel works in 64 bit mode but the kernel configure system has a bug that prevents the WiFi driver being selected.
Its there but cannot be selected. If you don't need WiFi, it will be OK as is.
The patches referred to at http://multipath-tcp.org provide all the MPTCP options and the configuration changes so that they can be selected.
The file mptcp-v4.10-d9c9f9273eb1.patch is a patch file that applies to vanillia sources 4.10.
If you are lucky, it will apply to the Raspberry Pi 4.10.y kernel too.
Do you know how to apply a patch by hand?
I can say that the patch does not apply correctly.
| Code: | patching file net/ipv4/tcp_output.c
Hunk #24 FAILED at 1282. |
That failed hunk will need to be investigated and applied by hand but only one failure is pretty good.
| Code: | /usr/aarch64-unknown-linux-gnu/usr/src/pi_sources # patch -p1 < mptcp-v4.10-d9c9f9273eb1.patch
patching file Documentation/networking/ip-sysctl.txt
patching file drivers/infiniband/hw/cxgb4/cm.c
patching file include/linux/skbuff.h
patching file include/linux/tcp.h
patching file include/net/inet_common.h
patching file include/net/inet_connection_sock.h
patching file include/net/inet_sock.h
patching file include/net/mptcp.h
patching file include/net/mptcp_v4.h
patching file include/net/mptcp_v6.h
patching file include/net/net_namespace.h
patching file include/net/netns/mptcp.h
patching file include/net/snmp.h
patching file include/net/sock.h
patching file include/net/tcp.h
patching file include/net/tcp_states.h
patching file include/net/transp_v6.h
patching file include/uapi/linux/if.h
patching file include/uapi/linux/tcp.h
patching file net/Kconfig
patching file net/Makefile
patching file net/core/dev.c
Hunk #1 succeeded at 6506 (offset 94 lines).
patching file net/core/skbuff.c
patching file net/core/sock.c
Hunk #7 succeeded at 1529 (offset 5 lines).
Hunk #8 succeeded at 1562 (offset 5 lines).
patching file net/ipv4/Kconfig
patching file net/ipv4/af_inet.c
Hunk #5 succeeded at 1853 (offset 2 lines).
patching file net/ipv4/inet_connection_sock.c
patching file net/ipv4/ip_sockglue.c
Hunk #2 succeeded at 759 (offset -1 lines).
patching file net/ipv4/syncookies.c
patching file net/ipv4/tcp.c
Hunk #30 succeeded at 2515 (offset 1 line).
Hunk #31 succeeded at 2751 (offset 1 line).
Hunk #32 succeeded at 2784 (offset 1 line).
Hunk #33 succeeded at 2830 (offset 1 line).
Hunk #34 succeeded at 3240 (offset 1 line).
Hunk #35 succeeded at 3483 (offset 1 line).
Hunk #36 succeeded at 3501 (offset 1 line).
Hunk #37 succeeded at 3517 (offset 1 line).
Hunk #38 succeeded at 3526 (offset 1 line).
Hunk #39 succeeded at 3538 (offset 1 line).
patching file net/ipv4/tcp_fastopen.c
patching file net/ipv4/tcp_input.c
Hunk #44 succeeded at 5696 (offset 1 line).
Hunk #45 succeeded at 5716 (offset 1 line).
Hunk #46 succeeded at 5727 (offset 1 line).
Hunk #47 succeeded at 5751 (offset 1 line).
Hunk #48 succeeded at 5783 (offset 1 line).
Hunk #49 succeeded at 5847 (offset 1 line).
Hunk #50 succeeded at 5897 (offset 1 line).
Hunk #51 succeeded at 5922 (offset 1 line).
Hunk #55 succeeded at 6086 (offset 6 lines).
Hunk #56 succeeded at 6103 (offset 6 lines).
Hunk #57 succeeded at 6149 (offset 6 lines).
Hunk #58 succeeded at 6168 (offset 6 lines).
Hunk #59 succeeded at 6192 (offset 6 lines).
Hunk #60 succeeded at 6253 (offset 6 lines).
Hunk #61 succeeded at 6263 (offset 6 lines).
Hunk #62 succeeded at 6271 (offset 6 lines).
Hunk #63 succeeded at 6283 (offset 6 lines).
Hunk #64 succeeded at 6306 (offset 6 lines).
Hunk #65 succeeded at 6403 (offset 6 lines).
Hunk #66 succeeded at 6500 (offset 6 lines).
Hunk #67 succeeded at 6528 (offset 6 lines).
Hunk #68 succeeded at 6540 (offset 6 lines).
Hunk #69 succeeded at 6600 (offset 6 lines).
Hunk #70 succeeded at 6615 (offset 6 lines).
patching file net/ipv4/tcp_ipv4.c
Hunk #2 succeeded at 364 (offset 3 lines).
Hunk #3 succeeded at 392 (offset 3 lines).
Hunk #4 succeeded at 417 (offset 3 lines).
Hunk #5 succeeded at 450 (offset 4 lines).
Hunk #6 succeeded at 470 (offset 4 lines).
Hunk #7 succeeded at 491 (offset 4 lines).
Hunk #8 succeeded at 511 (offset 4 lines).
Hunk #9 succeeded at 540 (offset 4 lines).
Hunk #10 succeeded at 548 (offset 4 lines).
Hunk #11 succeeded at 590 (offset 4 lines).
Hunk #12 succeeded at 726 (offset 4 lines).
Hunk #13 succeeded at 738 (offset 4 lines).
Hunk #14 succeeded at 786 (offset 4 lines).
Hunk #15 succeeded at 824 (offset 4 lines).
Hunk #16 succeeded at 862 (offset 4 lines).
Hunk #17 succeeded at 870 (offset 4 lines).
Hunk #18 succeeded at 878 (offset 4 lines).
Hunk #19 succeeded at 910 (offset 4 lines).
Hunk #20 succeeded at 1230 (offset 4 lines).
Hunk #21 succeeded at 1271 (offset 4 lines).
Hunk #22 succeeded at 1407 (offset 4 lines).
Hunk #23 succeeded at 1430 (offset 4 lines).
Hunk #24 succeeded at 1576 (offset 4 lines).
Hunk #25 succeeded at 1637 (offset 4 lines).
Hunk #26 succeeded at 1678 (offset 4 lines).
Hunk #27 succeeded at 1707 (offset 4 lines).
Hunk #28 succeeded at 1716 (offset 4 lines).
Hunk #29 succeeded at 1793 (offset 4 lines).
Hunk #30 succeeded at 1823 (offset 4 lines).
Hunk #31 succeeded at 1880 (offset 4 lines).
Hunk #32 succeeded at 1961 (offset 4 lines).
Hunk #33 succeeded at 1983 (offset 4 lines).
Hunk #34 succeeded at 2532 (offset 4 lines).
patching file net/ipv4/tcp_minisocks.c
Hunk #8 succeeded at 567 (offset 1 line).
Hunk #9 succeeded at 607 (offset 2 lines).
Hunk #10 succeeded at 615 (offset 2 lines).
Hunk #11 succeeded at 660 (offset 2 lines).
Hunk #12 succeeded at 820 (offset 2 lines).
Hunk #13 succeeded at 879 (offset 2 lines).
Hunk #14 succeeded at 892 (offset 2 lines).
patching file net/ipv4/tcp_output.c
Hunk #24 FAILED at 1282.
Hunk #25 succeeded at 1506 (offset 5 lines).
Hunk #26 succeeded at 1530 (offset 5 lines).
Hunk #27 succeeded at 1586 (offset 5 lines).
Hunk #28 succeeded at 1643 (offset 5 lines).
Hunk #29 succeeded at 1677 (offset 5 lines).
Hunk #30 succeeded at 1704 (offset 5 lines).
Hunk #31 succeeded at 1719 (offset 5 lines).
Hunk #32 succeeded at 1732 (offset 5 lines).
Hunk #33 succeeded at 1743 (offset 5 lines).
Hunk #34 succeeded at 1860 (offset 5 lines).
Hunk #35 succeeded at 2200 (offset 5 lines).
Hunk #36 succeeded at 2213 (offset 5 lines).
Hunk #37 succeeded at 2312 (offset 5 lines).
Hunk #38 succeeded at 2407 (offset 5 lines).
Hunk #39 succeeded at 2470 (offset 5 lines).
Hunk #40 succeeded at 2484 (offset 5 lines).
Hunk #41 succeeded at 2720 (offset 5 lines).
Hunk #42 succeeded at 3234 (offset 5 lines).
Hunk #43 succeeded at 3311 (offset 5 lines).
Hunk #44 succeeded at 3341 (offset 5 lines).
Hunk #45 succeeded at 3640 (offset 5 lines).
Hunk #46 succeeded at 3725 (offset 5 lines).
1 out of 46 hunks FAILED -- saving rejects to file net/ipv4/tcp_output.c.rej
patching file net/ipv4/tcp_timer.c
Hunk #7 succeeded at 312 (offset 1 line).
Hunk #8 succeeded at 586 (offset 2 lines).
Hunk #9 succeeded at 601 (offset 2 lines).
Hunk #10 succeeded at 642 (offset 2 lines).
Hunk #11 succeeded at 658 (offset 2 lines).
Hunk #12 succeeded at 715 (offset 2 lines).
Hunk #13 succeeded at 743 (offset 2 lines).
patching file net/ipv6/addrconf.c
patching file net/ipv6/af_inet6.c
patching file net/ipv6/ipv6_sockglue.c
patching file net/ipv6/syncookies.c
patching file net/ipv6/tcp_ipv6.c
Hunk #11 succeeded at 412 (offset 2 lines).
Hunk #12 succeeded at 435 (offset 2 lines).
Hunk #13 succeeded at 445 (offset 2 lines).
Hunk #14 succeeded at 498 (offset 2 lines).
Hunk #15 succeeded at 703 (offset 2 lines).
Hunk #16 succeeded at 727 (offset 2 lines).
Hunk #17 succeeded at 751 (offset 2 lines).
Hunk #18 succeeded at 768 (offset 2 lines).
Hunk #19 succeeded at 788 (offset 2 lines).
Hunk #20 succeeded at 829 (offset 2 lines).
Hunk #21 succeeded at 886 (offset 2 lines).
Hunk #22 succeeded at 947 (offset 2 lines).
Hunk #23 succeeded at 956 (offset 2 lines).
Hunk #24 succeeded at 996 (offset 2 lines).
Hunk #25 succeeded at 1018 (offset 2 lines).
Hunk #26 succeeded at 1044 (offset 2 lines).
Hunk #27 succeeded at 1085 (offset 2 lines).
Hunk #28 succeeded at 1139 (offset 2 lines).
Hunk #29 succeeded at 1277 (offset 2 lines).
Hunk #30 succeeded at 1294 (offset 2 lines).
Hunk #31 succeeded at 1429 (offset 2 lines).
Hunk #32 succeeded at 1443 (offset 2 lines).
Hunk #33 succeeded at 1494 (offset 2 lines).
Hunk #34 succeeded at 1543 (offset 2 lines).
Hunk #35 succeeded at 1571 (offset 2 lines).
Hunk #36 succeeded at 1603 (offset 2 lines).
Hunk #37 succeeded at 1666 (offset 2 lines).
Hunk #38 succeeded at 1732 (offset 2 lines).
Hunk #39 succeeded at 1770 (offset 2 lines).
Hunk #40 succeeded at 1807 (offset 2 lines).
Hunk #41 succeeded at 1821 (offset 2 lines).
Hunk #42 succeeded at 2053 (offset 2 lines).
patching file net/mptcp/Kconfig
patching file net/mptcp/Makefile
patching file net/mptcp/mptcp_balia.c
patching file net/mptcp/mptcp_binder.c
patching file net/mptcp/mptcp_coupled.c
patching file net/mptcp/mptcp_ctrl.c
patching file net/mptcp/mptcp_fullmesh.c
patching file net/mptcp/mptcp_input.c
patching file net/mptcp/mptcp_ipv4.c
patching file net/mptcp/mptcp_ipv6.c
patching file net/mptcp/mptcp_ndiffports.c
patching file net/mptcp/mptcp_olia.c
patching file net/mptcp/mptcp_output.c
patching file net/mptcp/mptcp_pm.c
patching file net/mptcp/mptcp_redundant.c
patching file net/mptcp/mptcp_rr.c
patching file net/mptcp/mptcp_sched.c
|
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Tue Jan 16, 2018 9:06 pm Post subject: |
|
|
All,
I'm in the process of finalizing a 17.0 profile version of the image. This is probably about a fortnight away, but for anyone who needs some 17.0 binary packages, check out the new https://isshoni.org/pi64pie binhost (which now has a complete set of everything on the image, including libreoffice, icedtea, firefox etc.).
I'm going to leave the 13.0 binhost (at https://isshoni.org/pi64) up for posterity, at least for a while, but it won't be autoupdated once the 17.0 image is out.
I'll provide cutover / release information shortly. This is just an advance notice for those who may find the new binhost useful ^-^
_________________
Regards,
sakaki |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Wed Jan 17, 2018 4:50 pm Post subject: |
|
|
| NeddySeagoon wrote: |
If you are lucky, it will apply to the Raspberry Pi 4.10.y kernel too.
Do you know how to apply a patch by hand?
I can say that the patch does not apply correctly.
| Code: | patching file net/ipv4/tcp_output.c
Hunk #24 FAILED at 1282. |
That failed hunk will need to be investigated and applied by hand but only one failure is pretty good. [/code] |
No, I don't know how to apply patches, but I will try to use examples from google...
Seems that I have same problem:
| Code: | pi64 ~ # cd /usr/src/linux
pi64 /usr/src/linux # wget http://multipath-tcp.org/patches/mptcp-v4.10-d9c9f9273eb1.patch
pi64 /usr/src/linux # patch -p1 --dry-run -d /usr/src/linux <mptcp-v4.10-d9c9f9273eb1.patch
......
Hunk #14 succeeded at 892 (offset 2 lines).
checking file net/ipv4/tcp_output.c
Hunk #24 FAILED at 1282.
Hunk #25 succeeded at 1506 (offset 5 lines).
......
Hunk #46 succeeded at 3725 (offset 5 lines).
1 out of 46 hunks FAILED
checking file net/ipv4/tcp_timer.c
Hunk #7 succeeded at 312 (offset 1 line).
......
|
However, tcp_output.c file exist in my system
| Code: | pi64 /usr/src/linux/net/ipv4 # ls -s -Z | grep tcp_output.c
108 ? tcp_output.c
|
Also I was trying to edit this file using MC and to save it. Everything is working, so at least MC running under root have permissions to edit and save this file.
I was trying to find strings what are related to tcp_output.c in mptcp-v4.10-d9c9f9273eb1.patch and there is a lot of strings... How to understand WHAT is going wrong when tcp_output.c is patched? How to understand 1282? This is NOT a string number in mptcp-v4.10-d9c9f9273eb1.patch related to tcp_output.c .. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
| Posted: Wed Jan 17, 2018 5:23 pm Post subject: |
|
|
orion777,
| Code: | | 1 out of 46 hunks FAILED -- saving rejects to file net/ipv4/tcp_output.c.rej |
Will give a hint.
| Code: | --- net/ipv4/tcp_output.c
+++ net/ipv4/tcp_output.c
@@ -1282,7 +1307,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
* eventually). The difference is that pulled data not copied, but
* immediately discarded.
*/
-static void __pskb_trim_head(struct sk_buff *skb, int len)
+void __pskb_trim_head(struct sk_buff *skb, int len)
{
struct skb_shared_info *shinfo;
int i, k, eat; |
There is 3 lines of context before the change and 3 lines after.
@@ -1282,7 +1307,7 tells the line numbers in the old and new files where the hunk should apply.
| Code: | -static void __pskb_trim_head(struct sk_buff *skb, int len)
+void __pskb_trim_head(struct sk_buff *skb, int len) |
is a line to remove, the - and a line to insert at the same place the +
Patch could not find something. Its probably be changed by something else before the patch was made.
Searching net/ipv4/tcp_output.c shows that | Code: | | static void __pskb_trim |
is not present in the file.
There is a context line | Quote: | | * eventually). The difference is that pulled data not copied, but |
though, that only occurs once.
The code around what looks like the failed hunk is
| Code: | /* This is similar to __pskb_pull_head() (it will go to core/skbuff.c
* eventually). The difference is that pulled data not copied, but
* immediately discarded.
*/
static int __pskb_trim_head(struct sk_buff *skb, int len)
{
struct skb_shared_info *shinfo;
int i, k, eat;
eat = min_t(int, len, skb_headlen(skb));
if (eat) {
__skb_pull(skb, eat); |
It looks like the failed hunk was trying to drop the static but instead of finding | Code: | | static void __pskb_trim_head(struct sk_buff *skb, int len) |
the original fire contains
| Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
That is the function has been changed from static void, to static int, which defeats patch.
Do you feel lucky?
Remove the static from | Code: | | static int __pskb_trim_head(struct sk_buff *skb, int len) |
with ${EDITOR} and save the change.
That's educated guesswork. You can keep all the pieces if I'm wrong :)
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
orion777
Apprentice
Joined: 15 Mar 2017
Posts: 207
Location: Riga, Latvia
|
| Posted: Tue Jan 23, 2018 6:38 pm Post subject: |
|
|
| NeddySeagoon wrote: |
That's educated guesswork. You can keep all the pieces if I'm wrong  |
Yes, You are right, since patch dry run returns no errors.
What console text editor can You suggest? As I'm using MC to edit text files, it is working Ok, but there is no line numbers and so..
Also I cant understand what means -1282,7 , because if I input go to string 1282 in net/ipv4/tcp_output.c , probably I get something else.. And what means -1282,7
_________________
The patch has been applied as follows:
| Code: | pi64 /usr/src/linux # patch -p1 < mptcp-v4.10-d9c9f9273eb1.patch
|
No errors.
However, I still have NO such https://wiki.gentoo.org/wiki/MultiPath_TCP options in make menuconfig  |
|
| Back to top |
|
|
Wallsandfences
Guru
Joined: 29 Mar 2010
Posts: 378
|
| Posted: Tue Jan 23, 2018 10:03 pm Post subject: |
|
|
Hey, great that a 64/rpi gentoo image exists.
At sakakis github the latest image seems to be 1.1.3 from last years octobre, is there a more recent one somewhere? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54579
Location: 56N 3W
|
| Posted: Tue Jan 23, 2018 10:08 pm Post subject: |
|
|
orion777,
I use nano for a text editor. Press Ctrl-C to get the line number the cursor is on.
Wars have been fought over editor recommendations. :)
| Code: | | @@ -1282,7 +1307,7 @@ |
means at line 1282 in the old file and line 1307 in the patched (new file)
I'm not sure what the ,7 is. I would guess its the character position on the line.
If you apply the patch, the line number you need is 1307 as that's where the failed hunk is now pointing.
Open menuconfig, press / and enter MPTCP I get lots of things starting with
| Code: | │ Symbol: MPTCP [=n] │
│ Type : boolean │
│ Prompt: MPTCP protocol │
│ Location: │
│ -> Networking support (NET [=y]) │
│ -> Networking options │
│ (1) -> TCP/IP networking (INET [=y]) │
│ Defined at net/mptcp/Kconfig:4 │
│ Depends on: NET [=y] && INET [=y] && IPV6 [=m]!=m |
The other options probably depend on that. Press 1 to go to that option,
Ahh, its hidden. Press z to see all the hidden options, then appears.
That means forced off.
Reading the Depends: on in the help, shows that IPv6 must be off.
With IPv6 off, the option appears
| Code: | │ │ [ ] MPTCP protocol (NEW) │ │
│ │ - - MPTCP: advanced path-manager control ---- │ │
│ │ - - MPTCP: advanced scheduler control ---- |
notice that things that depend on | Code: | | [ ] MPTCP protocol (NEW) |
are still hidden.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Last edited by NeddySeagoon on Tue Jan 23, 2018 10:19 pm; edited 1 time in total |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Tue Jan 23, 2018 10:12 pm Post subject: |
|
|
| Wallsandfences wrote: | Hey, great that a 64/rpi gentoo image exists.
At sakakis github the latest image seems to be 1.1.3 from last years octobre, is there a more recent one somewhere? |
Stay tuned, a 1.2.0 (built with profile 17.0) is in final testing now. Aiming to push it out on GitHub this week.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
