ipatch / theairportwiki

http://theairportwiki.com

TheAirPortWiki

You cannot help men permanently by doing for them what they will not do for themselves.

- Abraham Lincoln

The soon to be wiki for TheAirPortWiki

GitHub wiki development

When uploading a image within the .wiki/lib directory append the below URL in front of the image name within the lib dir to link against the image within this repo or wherever 🌈 else.

https://raw.githubusercontent.com/wiki/ipatch/theairportwiki/lib/

Usage

When working with Apple Time Capsule disks for a modern GNU+Linux distro, ie. Arch the below command will help mount the disk using CIFS

echo "mount the tc disk"
sudo -E mount.cifs //[tc.IP]/[PATH] [/local/path] -o "pass=[TC.DISK.PASSWORD],sec=ntlm,vers=1.0,file_mode=0777,dir_mode=0777,username=[$USER],uid=1000,gid=985"
echo "copy cmd"
rsync -a --no-o --no-g -h --info=progress2 -P /local/disk.qcow2 /local/path/

Note, I'm averaging about 10MB/s using rsynce to copy a large ~ 60GB qcow file across a network using a macbook with a gigabit to thunderbolt adapter, and writing the file to a SSD disk i installed in the time capsule.

Not exactly sure where the bottleneck on the network is arising, but my hunch makes me think write performance of the disk or server software running on the TC. (will test on a separate server in the future).

usage / gnu+linux / arch

to mount a time capsule shared disk using cifs as afp is being deprecated

sudo -E \ 
mount -t cifs //10.0.1.1/Data /mnt/tc \ 
-o "pass=$TC_PASSWORD,sec=ntlm,vers=1.0,file_mode=0644,dir_mode=0777,username=$USER,uid=1000,gid=985,serverino,cache=loose,mapposix,rsize=1048576,wsize=1048576,mfsymlinks"

the above is useful for navigating POSIX style symlinks throughout the filesystem

Usage / smbclient

went to down a bit of a rabbit hole today messing around with the smbclient cmd on my arch linux box, trying to connect to my time capsule using smbclient. i can obviously connect to it and mount with the above mentioned commands, but wanted to connect to it using smbclient just for the understanding of it.

echo "first if ip address or server name is uknown use nmap to find the ip address"
nmap -sT "10.0.1.*"; echo "obviously searching on a LAN, and knowing that the ip range is in the "10.0.1.x"

# output
Nmap scan report for 10.0.1.1

139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds

nmblookup -A 10.0.1.1
Looking up status of 10.0.1.1
        SNOWBRICK       <00> -         B <ACTIVE> <PERMANENT>
        WORKGROUP       <00> - <GROUP> B <ACTIVE> <PERMANENT>
        SNOWBRICK       <20> -         B <ACTIVE> <PERMANENT>

        MAC Address = 44444444444444444

then try and connect to the smb server, (unfortunately my apple time capsule only supports samba server version 1)

smbclient -L 10.0.1.1

# output
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

smbclient -L \\SNOWBRICK

⚠️ since the apple time capsule is running netbsd v4.0 and such an old version of the samba server certain options will need to be set in order to interact with the server

smbclient \
//SNOWBRICK/Data --option='client min protocol=nt1' --option='client use spnego=no' \
--password $TCPASSWORD

i got the same results using all the servernames

smbclient //snowbrick
smbclient //SNOWBRICK
smbclient //10.0.1.1

to avoid having to type the two options --option='client min protocol=nt1' --option='client use spnego=no everytime using the smbclient cmd add the below line to /etc/samba/smb.conf

# smb.conf
[global]
client use spnego=no
client use min protocol=nt1

🔥🔥🔥🔥

smbclient //snowbrick/data --password $TCPASSWORD

theairportwiki's Issues

Cross compiling to airport extreme 6th gen

Hey Chris,

First of all, thanks for the instructions and all your work, you have assembled very good information.

I have followed the cross compile NetBsd guide trying to create working cross compiling tools for the airport time capsule/airport extreme 6th gen device (my goal is to add some native functionalities like rsync and openvpn, perhaps give back snmpd that was stripped out from the firmware years ago) but, even if it gives apparently valid object files, the airport fails to run even a simple hello world.

The create filed had the following signature:

hello: ELF 32-bit LSB executable, ARM, version 1, statically linked, for NetBSD 6.0, not stripped

Have tried many combinations of eabi and float point options, stripping, tunning. Have built tools both in Linux and Netbsd 6.0 running on i386.

As the airport extreme runs Netbsd 6.0, I am focusing the cross-compiling on it, but I can switch to Debian Lenny or Ubuntu if needed -- I do not think that the host is the source of this issue, however.

# uname -a
NetBSD airport 6.0 NetBSD 6.0 (build.kernel-target.conf) #0: Mon Apr 29 18:35:13 PDT 2019  [email protected]:/BuildRoot/Library/Caches/com.apple.xbs/Sources/J28/AirPortFW-79100.2/Embedded/Firmware/NetBSD/Targets/J28/release/obj/build.kernel-target.conf evbarm

Got the chrunchprog inside it to check its signature and got:

$ file ps
ps: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for NetBSD 6.0, stripped

The SYSV in the signature is the only relevant difference. The cpu of my unit is a Cortex-A9 r4p0, running firmware version 7.9.1

I would appreciate any inputs.

Partition type for make_ffs

I am stuck trying to make an usb stick with an hfsplus partition and a ffs partition...

all partitions type Fat16/Fat32/hfsplus mount

partition appleufs (0xab) does will not work because mount_appleufs does not exists
mount_ffs on that does also not work... because of the wrong magic number

type 0xa9 (netbsd) 0xa6 0xa5 will also not work.
I am always getting always: Device busy...

so what am I doing wrong?

i used linux to partition
i used netbsd9 newfs to create the ffs.

sd0 at scsibus0 target 0 lun 0: <ASolid, USB, 0000> disk removable
sd0: fabricating a geometry
sd0: 60000 MB, 60000 cyl, 64 head, 32 sec, 512 bytes/sect x 122880001 sectors
sd0: fabricating a geometry
sd0: skipping partition 0, type 0xa9
dk0 at sd0: sd0f
dk0: 16777216 blocks at 16779264, type: msdos
dk1 at sd0: sd0g
dk1: 16777216 blocks at 33556480, type: appleufs
sd0: skipping partition 0, type 0xa6
sd0: skipping partition 0, type 0xa5
dk2 at sd0: sd0q
dk2: 16777216 blocks at 83894272, type: hfs
dk3 at sd0: sd0u
dk3: 16777216 blocks at 100673536, type: appleufs
dk4 at sd0: sd0y
dk4: 5427201 blocks at 117452800, type: msdos

Website Is Down

It used to work, but now, whenever I go to theairportwiki.com, this is what it says:

Hello, theairportwiki.com !

mediawiki site is no more, most if not all content that was there is here

4th Gen Airport Time Capsule - Compile rsync

Hi, I am following the guide at https://github.com/ipatch/theairportwiki/wiki/build-a-cross-compile-NetBSD-toolchain-armv6-Notes
Setup a NetBSD 9.0 VM on Proxmox and trying compile rsync for NetBSD 4.0 and earmv5 in it instead of the airport (not brave enough to try doing it on the target yet). You mentioned rsync-3.1.3nb1 (need to compile a simple perl working) and i am trying to figure out how exactly to do that. Can you please help?

had to remove large files

---

Notes - Trying to run go binaries on Airport

Unfortunately I wasn't really able to get it to work. But here's some notes in case someone else wants to pick up where I left off.

First thank you to @gchehab for providing the precompiled BSD base sets (#4) which makes spelunking a lot easier. It includes gcc so while it's possible to compile newer versions of curl, perl, rsync, etc. directly on device, this is a bit of a pain and it's probably quite slow to do so as well. Go has legendary cross-compile abilities (since it basically avoids libc entirely and makes direct syscalls), and it natively supports arm v6 + netbsd. Plus binaries are statically linked by default. So I thought this would just work out of the box.

Issue 1: Newer versions of Go use a version of lwp_park syscall not supported on netbsd 6. This is described in https://mail-index.netbsd.org/tech-pkg/2018/07/05/msg019971.html – You can either use go1.9, or just revert the aforementioned commit.

Issue 2: While that's sufficient to have the resulting binary begin the go runtime initialization, it gets stuck after the call to lwp_park (semasleep). It seems that there's a deadlock somewhere, nothing is waking it up (semawakeup). Tracing with gdb shows that there's only one thread active, so something about the thread creation seems wonky.

I also tried using the most modern go version with the above commit reverted. This crashes even before the call to lwp_park, on the thread creation itself which returns EINVAL. After some debugging, seems something is weird with the lwp_mcontext_init call, it sets R15 (PC) to the address to resume from (lwp_tramp), but for some reason the alignment of the function seems to be off and bsd doesn't like it. I didn't really debug further, I just brute-forced by inserting nop until the alignment worked out and it got past this. Unfortunately it still hung on the lwp_park.

The hang there might be a kernel issue, I see netbsd had some kernel changes to support Go (Go is also unique in that it makes syscalls directly which I recall is not really supported on BSDs, so I can imagine that it's doing something which bsd doesn't like).

If anyone wants to give this a shot, then trying to see why the lwp_create doesn't actually create a new thread is probably the way to go. I suspect that this created thread is what would send the wakeup call and get things moving.

Persisting hostap changes

Anyone figured out how to get changes made to the hostap config to persist? It seems that while you can set it, then restart the hostap daemon and it works for a short while, after a few hours something resets the config.