<fpsusername[m]>
Unfortunately I still don't have the new clip
rua has quit [Quit: Leaving.]
ashkan has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
aleasto has quit [Quit: Konversation terminated!]
Tapper has quit [Ping timeout: 480 seconds]
nitroshift has quit [Remote host closed the connection]
<stintel>
Habbie: mooi :)
<Habbie>
dank u!
dorf has joined #openwrt-devel
<dorf>
minor issue with Tor. the default torrc has the hidden service dirs pointing at /var/lib/tor/ which is super bad.
<karlp>
minor/superbad?
<karlp>
file an issue?
<dorf>
well, it's minor but the result is super bad if not changed :)
<karlp>
what's wrong, isn't that like var/lib/www for apache webdir roots?
<karlp>
what should it be?
<dorf>
because /var/lib/ maps to /tmp, so non-persistent. user creates a hidden service, keys get generated, user reboots router, keys go *poof*
<dorf>
it could be any number of places where user tor has write perms.
<dorf>
that is, unless I've somehow managed to bodge my external usb config. could also be that :)
<dorf>
yeah, I can't see anything obviously wrong with my mounts or fstab, so am I right in believing /var/ is being mapped to /tmp by design?
<karlp>
by default, but can be configured separately.
<dorf>
that's what I'm asking. so by default /var/ is mapped to non-persistent tmpfs.
<dorf>
so anything and everything that requires persistence should be configured by default to go elsewhere, no?
<dorf>
it's one of those things that isn't immediately obvious, and with the torrc pointing to /var/lib/tor/ for hidden service configs, you just configure it and assume all is good.
<dorf>
and then some weeks down the line when you randomly check your hidden service is still working, and it isn't, it's just as unobvious why.. files appear intact.. until you check the hostname of the hidden service :)
brpr has joined #openwrt-devel
<brpr>
PaulFertser, we're back on track! I've replaced the coil and HE'S ALIVE!!!
<PaulFertser>
brpr: congrats :)
<brpr>
I've also got an USB to UART adapter and a working Linux TFTP server, so this will be much easier now.
rua has joined #openwrt-devel
<Habbie>
fpsusername[m], have you considered asking KPN for GPL sources to uboot? so we can at least figure out what the password mechanism is? :)
<fpsusername[m]>
Nope. I don't have any contact or reputation with them, so I highly doubt that they'll give it
<fpsusername[m]>
Probably all closed source
<Habbie>
well, uboot is GPL, so they have to, i think
<brpr>
PaulFertser, my USB to UART is outputting 3.9V, still safe to plug into router?
<PaulFertser>
brpr: 3.9 on Tx pin?
<PaulFertser>
brpr: and using the same DMM you measure how much on target's Tx pin?
<brpr>
yes, 3.9 on Tx
<brpr>
target 3.3v
<PaulFertser>
brpr: hm, that's odd and a bit too scary. I'd investigate why the adapter does that.
<PaulFertser>
brpr: I suggest you get datasheet for the ICs used on that adapter to see where this voltage is from.
<Habbie>
any chance your usb to uart has a 3v3/5v jumper switch?
<brpr>
it does have it. set to 3v3
<Habbie>
ok
goliath has joined #openwrt-devel
linusw has quit [Quit: Connection closed for inactivity]
<brpr>
I'm returning the USB to UART, absoulute max voltages on the QCA9531 are 3.6V
<brpr>
PaulFertser, back to the Pi :)
<mrkiko>
brpr: yes, absolutely congrats for your persistence
<mrkiko>
brpr: are you able to boot openwrt vbia initramfs or flashing it ??
rua has quit [Quit: Leaving.]
<brpr>
mrkiko initramfs.
<brpr>
mrkiko, also, thanks :)
Kali_ has quit [Quit: Lost terminal]
rua has joined #openwrt-devel
<mrkiko>
brpr: what's your device model name?
aleasto has joined #openwrt-devel
<brpr>
ASUS RT-AC55U
<mrkiko>
great!
<brpr>
one of my biggest projects at 14
<brpr>
14 years old, keyboard is so sensitive :(
<brpr>
PaulFertser, picocom somehow broke and was displaying garbage. minicom works just fine.
<PaulFertser>
brpr: probably you've forgotten to set baud rate? Sounds too odd to be true ;)
<brpr>
No, I've set it alright, it's displaying SOME parts of the bootlog but still craps out at some point, minicom is stable
ashkan has joined #openwrt-devel
<brpr>
PaulFertser, now where did we leave off lol
<brpr>
oh yeah, the switches
<PaulFertser>
brpr: eth1 not passing traffic probably due to incorrect &phy configuration, for that the vendor dmesg should be looked at carefully.
TomasB has quit [Quit: Lost terminal]
<brpr>
PaulFertser, ag71xx ag71xx.0: eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd036, driver=Atheros AR8216/AR8236/AR8316]
<brpr>
only mention of PHY that isn't physical :P
<PaulFertser>
brpr: doesn't mention eth1 at all in the vendor log?
<brpr>
eth1: Atheros AG71xx at 0xba000000, irq 5, MAC
<brpr>
and then MAC
<PaulFertser>
brpr: I suggest you put a link here to your full vendor dmesg. And hope someone else can help you digging, I'm very busy atm.
Grommish has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
rua has joined #openwrt-devel
rsalvaterra has quit [Quit: Leaving]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
aleasto has quit [Remote host closed the connection]
ashkan has quit [Ping timeout: 480 seconds]
swalker has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Borromini has joined #openwrt-devel
brpr has quit [Ping timeout: 480 seconds]
bobthebuilder999 has joined #openwrt-devel
swalker has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
mrkiko has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
cp- has quit [Remote host closed the connection]
<Namidairo>
dangole: that embedded eeprom looks pretty edit-unfriendly with the 4-byte groupings and truncation
<dangole>
Namidairo: lol, it's not intended to be editted. EEPROM is usually stored in a physical EEPROM or partition of MTD device -- which doesn't exactly make it more edit-friendly. In case of embedding it into DT, instead of defining the array of u32 values, you can also use this:
<Namidairo>
but I suppose anyone who wants to set their mac can obviously would do it in a different layer, and anyone who wants to **** with embedded values should know what they're doing
<dangole>
to include a file
<Namidairo>
yeah I was wondering if there was a defined way to include a file like that
<dangole>
a method for setting permanent mac address has to be outside of device tree. U-Boot's board_late_init_f() would be the classic candidate to patch it into DT from U-Boot environment.
<Namidairo>
I'd assume anyone who's bothered to purchase a OUI prefix has engineers that know what they're doing. probably. maybe.
<Namidairo>
nevermind, I just remembered that there's an entire model of TP-Links circulating with the wrong chipset magic at the start of their eeprom
<Grommish>
Anyone know a way to tell if the "arm" on a target is armv7 or armv7 from a CONFIG_ flag or something?
<Grommish>
err.. armv8
<Namidairo>
armv8 is 64-bit isn't it, and it looks like there are a number of config flags around that...
<Grommish>
Thanks. I'll look :) The build system just lumps everything under "arm" and sets different feature sets rather than breaking them out :(
<dangole>
Grommish: ...and FPU flags are apparently not even applied at all... we'll need to impove include/target.mk....
dangole has quit [Quit: Leaving]
<Grommish>
Ick. and I was hoping simple
<Grommish>
That would touch every arm target.. Not it.
<Namidairo>
CONFIG_ARM64 is probably a little naive, and I'm not too sure whether it's universal on all the current armv8 using targets
<Grommish>
Namidairo: Thanks :) Any idea if OpenWrt targets anything other than armv7 and armv8? no standard 'arm' or 'armv5e' or whatever?
<Grommish>
It sets itself to just 'arm-openwrt-linux-muslgnuabi' which it really isn't
<Grommish>
should be like armv7-openwrt-linux-muslgnibihf