<Thagabe>
Hello all, could I ask for some assistant creating a config file (UCI) for DSA? Basically a tool someone created was using uci commands for swconfig but I'm trying to make it DSA compliant. I managed to make it work on my test device but when i built an image from it it didnt work right of the bat. The script did not pick up @device[4] (on wrt1900acv1) which is enable by default which is port 4 on my router. however with
<Thagabe>
(wrt3200acm) did not show anything past @device[1]='br-lan' but if I picked the lan4 I had to manually enable the lan4 on the web gui THEN it would show up as @device[2]. How does DSA choose to assign these devices?
gch981213 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
matoro has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
* russell--
just popped open a calix gigapoint 803G ONT and got (with difficulty) a bootlog
valku has joined #openwrt-devel
<russell-->
serial console seems to be operating at 120180 baud, screen isn't doing a good job decoding at that baud, so sucked the bootlog down with pulseview
<dwfreed>
120180 ? that's a really odd number
<russell-->
yes, it is
valku has quit []
<dwfreed>
4,980 over 115,200
<russell-->
it is probably either an out-of-spec oscillator or intentional obfuscation
<damex>
is ar9380 really obsolete? found full size board with 3 antennas :)
<russell-->
damex: i still have a device that was EOL'd in 2005
<damex>
oh my
<damex>
russell--: i just wonder if that old cards could have any good use in modern day and age
<damex>
since we have some features of wifi6 available for 2.4ghz too :)
<slh64>
damex: obsolete is such s flexible term... I'm still using 802.11g /clients/, but I surely won't buy anything below 802.1ac/ wave2 anymore (and I am using) prefering 802.11ax for new purchases)
<slh64>
11g to 11n wasn't much of a real world improvement (but it paved the way), ac and ax really are
cbeznea has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
lucenera4 has joined #openwrt-devel
lucenera has quit [Read error: Connection reset by peer]
Borromini has joined #openwrt-devel
lucenera4 has quit []
lucenera has joined #openwrt-devel
akanouras has quit [Remote host closed the connection]
bluew has quit [Ping timeout: 480 seconds]
Thagabe has quit [Quit: Leaving]
KGB-2 has quit [Ping timeout: 480 seconds]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
<mrkiko>
slh64: out of curiosity, what device are you using as AP?
<mrkiko>
russell--: bcm at it's finest :D
KGB-2 has joined #openwrt-devel
mrkiko has quit [Quit: leaving]
mrkiko has joined #openwrt-devel
robimarko has joined #openwrt-devel
danitool has joined #openwrt-devel
f00b4r0 has quit [Quit: bbl]
* russell--
is dumping firmware over serial from CFE
<dwfreed>
russell--: what's funny is I used to work around the corner from Calix
<russell-->
i asked to buy one of these devices about 4 years ago after seeing them on display at a conference and was asked to sign an NDA just to buy one, and i laughed and said i'd just buy one on e-bay.
<dwfreed>
lol
<russell-->
but, being new at the time, there weren't any on e-bay. but 4 years later, one lands in my lap
<robimarko>
Thats new, NDA to buy a device
srslypascal has quit [Ping timeout: 480 seconds]
<russell-->
i got serial working by switching to another usb-serial device, which seemed better able to cope with the baud variation
<neggles>
stintel / robimarko: oh are we trying to crack a hash?
<neggles>
(or desoldering it and attaching to a T48/T56/TL866 II)
<russell-->
neggles: the hash 2023-01-19 01:52 stintel: so the hex has should be e597301a1d89ff3f6d318dbf4dba0a5abc5ecbea if I'm not mistakenit was posted in the channel about 24 hours ago
<neggles>
dumping from CFE is the most straightforward way though
<russell-->
oops, ... that's the hash and the algorithm was posted too
<neggles>
oh just dumb sha1
robimarko has quit [Read error: No route to host]
robimarko has joined #openwrt-devel
<mrkiko>
russell--: are you able to get a root shell? In the end of your last bootlog I've seen a bcm shell or something
srslypascal has joined #openwrt-devel
<dwfreed>
neggles: yes, just dumb sha1 :)
<russell-->
mrkiko: yeah it's a limited shell. ps shows /bin/bash is running but there isn't anything obvious to spawn one
<dwfreed>
neggles: we have no idea what the search space is, but it's probably 8 characters or less; if you find an answer, let me know, I can test it easily
<mrkiko>
guess you tries several things like "!" and so on
<neggles>
heh. they made it device-specific with some of the later ones.
<neggles>
my T20 does some crimes with the serial number, and what it's doing in the decompiled binary is *not* the same as what's in the GPL dump.
<neggles>
...so i just binpatched the JNE to a JEQ
<dwfreed>
heh
borek has joined #openwrt-devel
<russell-->
neggles: my math suggests my serial dumping be done when i wake up tomorrow
<neggles>
sounds about right
<russell-->
13-ish hours
<neggles>
dumping a 256MiB chip at 115200 took me 27ish
<neggles>
wonder if i uploaded that script somewhere
<mrkiko>
russell--: do you plan to modify the dump and write it back?
<neggles>
dwfreed: fwiw, it's probably a 32-char all-uppercase hex string
<dwfreed>
oof
<russell-->
mrkiko: just examine to begin with, i don't have an immediately obvious way of writing it back
<russell-->
nor, for that matter, anything to write back
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
borek has quit [Remote host closed the connection]
<neggles>
oh dear. did stintel take this out of the u-boot sources from the gpl tarball
<robimarko>
Probably
<neggles>
because it's the same as the hash that's in my gpl sources, which does not reflect what the binary on the device actually does
goliath has joined #openwrt-devel
<oliv3r[m]>
I want to do this in some assembly: lirSEL, ~(RTL839X_PLL_CTRL0_CMU_DIVN2 | RTL839X_PLL_CTRL0_CMU_NCODE_IN) but the preprocessor makes it 64bits. How can I cast this to 32 bits?
<oliv3r[m]>
The pre-processor generated stuff (my own handrolled genmask) produces the following: `Error: operand 2 must be constant `li $t7,~(unsigned long)((((~(0))-((1)<<(12))+1)&(~(0)>>(32-1-(19))))|(((~(0))-((1)<<(4))+1)&(~(0)>>(32-1-(11)))))'` so not sure what its complaining about. I suppose the preprocessor won't do the bit inversion?
borek has joined #openwrt-devel
<nbd>
oliv3r[m]: i think it's most likely complaining about the (unsigned long) bit
<nbd>
:)
<nbd>
that's C, not assembly
<oliv3r[m]>
yeah, i tried several combinations, I was hoping the pre-processor would deal with that. I know the preprocessor was pretty smart in doing some basic operations (math, shifts ands/ors, not/invert) on constants
<oliv3r[m]>
but if I don cast it, it generates a 64 bit long value :S
<nbd>
maybe do & 0xffffffffU
<neggles>
`UL()`
<neggles>
macros for days
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<oliv3r[m]>
ohh right, of course; d'oh
<oliv3r[m]>
so can I do 'and' via the pre-processor?
<oliv3r[m]>
sadly, also that macro is not allowed :S
<jow>
oliv3r[m]: the preprocessor should be able to do bitops
<oliv3r[m]>
i know i can write assembly for it :p but if the preprocessor can do it; why not :)
johnf has joined #openwrt-devel
<jow>
oliv3r[m]: could you provide some more context though? I don't undertstand how the cpp "makes" the values 64bit, it should just expand defines to code
<oliv3r[m]>
so the PLL on the realtek needs to be (re)configured whilst running from SRAM, since there's only very little space, and we want to do as little as possible from SRAM, that code is written in assembly (not by me, though maybe it would have worked as C code -> object -> sram just fine ... who knows. Anyway, I do want to re-use as much of the normal macro's, defines etc as possible, and ideally let the preprocessor do as much work as
<oliv3r[m]>
possible. I could hard-code the values (they are currently) but that's even less appealing :)
<jow>
so you want to use constants in an inline asm expression and the code thoe macros expand to is invalid?
<jow>
s/constants/defines/
<jow>
is it a .c file with inline asm?
<jow>
in any case the precompiler will *not* turn `((((~(0))-((1)<<(12))+1)&(~(0)>>(32-1-(19))))|(((~(0))-((1)<<(4))+1)&(~(0)>>(32-1-(11)))))` into a constant integer literal expression which you can paste into asm code
<dhewg>
nl80211.h is a nice standalone header, that's like the other end of the spectrum compared to bpf
<jow>
well the entire bpf business is a clusterfuck imho
<jow>
cross compilation is simply no concern right now
<dhewg>
having digged a little though it in the last two days I approve of that message
<jow>
apparently it is expected to have a full fldged llvm toolchain on target and reconfiguring bpf things implies compiling stuff
<Ansuel>
now i understand the difficulties in gcc trying to standardize the thing and llvm say nha we don't need that :D
<jow>
it's like running varnishd with it's weird C-based configuration "file"
<jow>
which is actually compiled into a shared library before server start
<jow>
you can only hope for alternative/leaner toolchains becoming available
<jow>
something akin to tcc
<jow>
or using precompiled objects and simply linking on target
<jow>
or writing generic bpf programs which can be "configured" through maps and the like
Borromini has quit [Quit: Lost terminal]
<mrkiko>
how does unetd use bpf?
<oliv3r[m]>
so one final issue i have, is that as doesn't like 0U, (or 0UL) so how can I make it use 32bits and not 64bits (i dont' even know where it's getting that idea from
<nbd>
mrkiko: whenever vxlan tunnels are used, it attaches a bpf program to them to fix up tcp mss
<nbd>
in the future i also want to add a feature that redirects ip traffic on vxlan tunnels to the base wg interface where possible, and does the reverse on the other side
<nbd>
in order to optimize away the tunnel encap overhead
valku has joined #openwrt-devel
<oliv3r[m]>
jow:
<oliv3r[m]>
instead of loading a mask, and doing a and + or; I could also instead, just use the 'ins' instruction I think
<oliv3r[m]>
what the code does, is a read-modify, write. e.g. read register, mask out the bits we want to keep; or-in the new bits; which I think the 'ins' instruction does in one go
<oliv3r[m]>
ah crap, while that will work in theory, I still need to set the 'size' using the mask in some way
Ryncewynd has joined #openwrt-devel
<Ansuel>
btw i'm following the x86: use mkfs.fat, sed, mmd and mcopy from staging_dir thing
<Ansuel>
and i read something interesting
<Ansuel>
unsetting the PATH for anything the is not host tool compilation
<dhewg>
fyi, you probably already now, restart rpcd if replacing libiwinfo and rpcd-mod-luci is a nice usecase too, because it doesn't link but dlsym()
<nbd>
Znevna: force-create is not necessary
<Znevna>
sweet
<Ansuel>
dhewg ok then thanks for the extra look
<Ansuel>
currently fixing a stupid thing with upstream kernel and then I will take care of brake the ABI :D