cmonroe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cmonroe has joined #openwrt-devel
<neggles>
f00b4r0: nice! happy to test and add my Tested-By if you like
<neggles>
and when i say eth0 doesn't work I mean ether0 in routerOS - the port comes up and packets flow for a second or two, then it stops receiving packets, the switch it's plugged into starts freaking out, and the port continues to show link up even after unplugging it
<neggles>
ether1 is fine though
ecloud__ has joined #openwrt-devel
ecloud_ has quit [Read error: Connection reset by peer]
rua has quit [Quit: Leaving.]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
rua has joined #openwrt-devel
<neggles>
svanheule: interesting, mikrotik did the same thing with the CSS326 and CRS326, except the CSS version has a 2MiB flash and no u-boot / linux (SwOS runs directly as a baremetal monolithic app, and appears to be based on some weird RTOS)
<neggles>
csrf1: the flash chip node should be named `flash@0` (or flash@1 if it's on SPI CS1, etc) with an alias of `flash0`, or `nor0` if there's also NAND in the system
<neggles>
compatible line should be `compatible = "brand,actualpartnumber", "jedec,spi-nor";`
<neggles>
friggin weird setup. two broadcom 4x4 miniPCIe radios, octeon III CN7020 dual-core @ 1GHz
<Grommish>
That could be fun
<neggles>
it has SPI NOR, CFI NAND, *and* eMMC
<neggles>
"software defined radios" in this case means "two 4x4 broadcom cards which can be set to either band"
<Grommish>
Well, Broadcom though.. I wonder if you can swap those out if they are really mPCIe
<neggles>
so you can configure as 4x4 2.4GHz + 4x4 5GHz, dual 4x4 2.4GHz, dual 4x4 5GHz, or supposedly combined 8x8 5GHz
<neggles>
yeah they'll swap out just fine
<neggles>
might put two of those 4x4 MT7915 cards in
<Grommish>
I need to find someone to mount a mPCIe header to my itus still
<Grommish>
Just to do it
<Grommish>
everything else is still there, but they just never populated the pads
<neggles>
i don't think this AP ever got used
<neggles>
still has the shipping plastic on, no dust
<Grommish>
Nice!
<neggles>
now to annoy cambium support for a gpl tarball
<neggles>
what the hell
<neggles>
this has a 16mbit SPI NOR, a 16mbit parallel NOR, and a 4GiB eMMC
<neggles>
why both kinds, cambium
Q__ has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit []
aparcar[m] has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
pavlix has quit [Quit: Bridge terminating on SIGTERM]
olmari has quit [Quit: Bridge terminating on SIGTERM]
lipnitsk has quit [Quit: Bridge terminating on SIGTERM]
MatMaul[m] has quit [Quit: Bridge terminating on SIGTERM]
t4h4[m] has quit []
John[m]12345678 has quit [Quit: Bridge terminating on SIGTERM]
schmars[m] has quit [Quit: Bridge terminating on SIGTERM]
Movedtomkg20001mkg20001io[m] has quit [Quit: Bridge terminating on SIGTERM]
whatevs111[m] has quit [Quit: Bridge terminating on SIGTERM]
evils[m] has quit [Quit: Bridge terminating on SIGTERM]
will[m] has quit []
fieryeagle954[m] has quit [Quit: Bridge terminating on SIGTERM]
nick[m]1234 has quit [Quit: Bridge terminating on SIGTERM]
znullptr[m] has quit []
decke[m] has quit [Quit: Bridge terminating on SIGTERM]
mkg20001 has quit [Quit: Bridge terminating on SIGTERM]
hexagonwin[m] has quit [Quit: Bridge terminating on SIGTERM]
JuniorJPDJ has quit []
lykos153 has quit [Quit: Bridge terminating on SIGTERM]
fpsusername[m] has quit [Quit: Bridge terminating on SIGTERM]
bluse-blue[m] has quit [Quit: Bridge terminating on SIGTERM]
<mrkiko>
slh: thanks! But I am still confused - how might I help in that process, if possible
grift has quit [Quit: Bye]
<mrkiko>
slh: I mean - what are the main barriers for acceptance of the patch; sure, the main difficulties to overcome
grift has joined #openwrt-devel
<neggles>
rmilecki: wait a dang second. `ucidef_set_interface_lan "someport anotherport" "dhcp"` will make a device into a DHCP client by default inste- *it does!*
<neggles>
there are *so many devices* which should have that in there by default. yikes.
aparcar[m] has joined #openwrt-devel
<rmilecki>
neggles: feel free to send patches for review :)
<f00b4r0>
Ah ha, Kalle has taken robimarko's patch in pending. Progress!
Tapper has joined #openwrt-devel
<neggles>
rmilecki: would I need to do DEVICE_COMPAT_VERSION shenanigans to warn people about the change? I'd be surprised if there were many complaints about "From <Next Major Release>, AP devices now default to DHCP client rather than static IP with DHCP enabled"
<f00b4r0>
I've declared the PoE out led but it seems ledtrig-gpio is hosed (at least on this platform) and it doesn't work.
<f00b4r0>
I don't feel like going down this rabbit hole just yet so I'll leave it like that :)
<neggles>
is the gpio exported?
<f00b4r0>
yes
<neggles>
hm. i wonder if that breaks it, though if anything it should be the other way around? *shrug*
<f00b4r0>
writing to the gpio number in the led trigger gives an IO error and "IRQ setup failed" messages in dmesg
<f00b4r0>
that's a bigger problem than I'm willing to tackle now.
<f00b4r0>
in any case, that aside, everything else seems to work. In line with what we discussed yesterday with rmilecki I've assigned both ports to lan. I've also hooked one port to eth1, the other goes to eth0 through switch port 2 (afaik there is no way to bypass the switch there)
ecloud__ has quit [Ping timeout: 480 seconds]
<neggles>
f00b4r0: yeah, IMO it should be `ucidef_set_interface_lan "eth0 eth1" "dhcp"`
<f00b4r0>
neggles: wouldn't that complicate first access? AIUI most people expect a fresh install to respond at 192.168.1.1?
<neggles>
for this particular device, maybe. but, the industry standard across practically everyone (who is not mikrotik - and they get away with it because of mac-winbox) is for an AP-type device to be a DHCP client
<neggles>
the static default is fine in and of itself, but it comes along with a DHCP server and IPv6 ND enabled broadcasting RAs and advertising itself as gateway/DNS
<f00b4r0>
yeah. In fact if there were a way to have the static default and no dhcp server, that'd be my preference.
<neggles>
well see cambium/ubiquiti/cisco/aruba/mist/meraki have a solution for that as well fwiw
<f00b4r0>
anyway, let me know if it works for you and I'll add your Tested-by before sending to the m-l :)
<neggles>
e.g. cambium APs are available at 169.254.x.y where X and Y are the last 2 octets of the MAC address
<neggles>
f00b4r0: will do! it's building right now :)
<f00b4r0>
👍
<neggles>
for OpenWrt the obvious/easy solution would be to use 169.254.1.1 for the default static, but have a DHCP client running as well (this is the approach cambium takes on their PMP/PTP product lines, .1.1 for AP radios and .1.2 for client radios)
<neggles>
this lil guy doesn't *quite* fall into that bucket
<neggles>
f00b4r0: hm. i forgot that netinstall/tftpboot only works through ether1
<f00b4r0>
I mention that in the commit message :)
<rmilecki>
neggles: i don't think DEVICE_COMPAT_VERSION change is required for that, but that is my opinion
<neggles>
yah, but, ether1 on my device is... unhappy...
<neggles>
hopefully it still works in routerboot :P
<neggles>
can just flash it with an spi clip if not.
<f00b4r0>
hardcore :)
* neggles
just likes to make sure all these routers know their place
ecloud_ has joined #openwrt-devel
<neggles>
f00b4r0: i have remembered a thing, these have what looks like a factory-programmed TSOP-14 STM32 on the bottom
<neggles>
and AIUI it's doing PoE stuff
<neggles>
maybe stm8? part markings are generic'd
<f00b4r0>
ok?
<neggles>
...yeah sorry never mind, thought it might be related to the poe led thing but no, that's the trigger, not the output. my bad
<f00b4r0>
no the led really is a problem (bug?) in ledtrig-gpio
<f00b4r0>
since that's purely cosmetic, I'm not inclined to care too much :)
<f00b4r0>
the led itself work
<neggles>
yeah :P
<f00b4r0>
=s
<neggles>
that's a driver problem which is not related to the device itself
danitool has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
borek has joined #openwrt-devel
<f00b4r0>
well well well
<f00b4r0>
rmilecki: so I took a quick google look at the devices I mentioned yesterday. Turns out they are _all_ indoor/outdoor 2-port hotspots AP
borek has quit []
<f00b4r0>
I'm going to send a patch to move them all to `ucidef_set_interface_lan "eth0 eth1"`, CCing you. I expect there will be ripples in the userbase ;)
<rmilecki>
f00b4r0: souds good
<f00b4r0>
I'll be hiding if bombs start flying :)
<neggles>
I still think they should be "dhcp" as well.
<neggles>
that's the behaviour for *every other platform* with AP devices
<f00b4r0>
neggles: only 1 device has "dhcp" on ath79
<f00b4r0>
I'm not jumping that far yet
<neggles>
I am guessing that's because nobody knows it's there...
<f00b4r0>
I'm pretty sure just the one change I'm about to make is going to get me flak'd
<neggles>
oh. i typed a message earlier and did not send it
<neggles>
it was, rmilecki: OK, I agree - IMO they should all be set to DHCP client as well, but I feel like a sweeping change such as this merits some ML discussion and perhaps an explicit policy on categorizing devices into "gateway" (first port WAN, LAN is static, DHCP server enabled) / "access point" (all ports LAN, DHCP client with fallback static IP) /
<neggles>
etc.
<Grommish>
neggles: There is already a structure in place (sorta).. target.mk:DEVICE_TYPE?=router So it isn't that outlandish
<jow>
neggles: DHCP with fallback IP might be acceptable
<jow>
ideally mdns by default
<neggles>
169.254.x.y where x/y = last 2 octets of label-mac, and with mDNS enabled
<neggles>
or just 192.168.1.1 still.
<jow>
yeah
<jow>
unfortunately a certain share of the userbase will not be able to deal with devices requiring dhcp by default
<Habbie>
i haven't read all of it, but i find ipv6 link local (fe80::) to be a nice fallback
<neggles>
oh yeah people will definitely complain.
<neggles>
I find the 169.254.x.y solution to be quite elegant, and the 169.254.1.1/2/3 (gateway/AP/switch) approach works as well
<jow>
will it works with macOS and Windows ootb?
<neggles>
yep
<jow>
-s
<jow>
then finer with me
<jow>
-r
<jow>
Linux users will cook their own soup anyway
<neggles>
e.g. cambium ePMP client radios default to 169.254.1.2, specifically so you can plug a PC into the ethernet port of an unconfigured radio (they default to DHCP) and access it
<neggles>
that IP continues to be accessible from the LAN side of the device unless you explicitly disable it, works great for anti-lockout
GNUmoon has quit [Remote host closed the connection]
<f00b4r0>
patch sent, yikes
<neggles>
works with linux too btw
GNUmoon has joined #openwrt-devel
<jow>
neggles: only if avahi is installed, or?
<neggles>
169.254.0.0/16 is just link-local auto-assigned
<jow>
I mean linux does not do 169.254.x.y by default
<f00b4r0>
neggles: imho the 192.168.1.1 default is something that a lot of people (myself included) rely on and expect. Doing away with that is going to face resistance
<neggles>
f00b4r0: i'm not against keeping 192.168.1.1 if people really want to do that, as long as it comes with 'not having a DHCP server and ipv6 RAs enabled`
<f00b4r0>
*nod*
<neggles>
and this would be specifically for devices that are intended to be APs, typically with 1-2 ethernet ports
<neggles>
i.e. if the factory firmware's default configuration is "DHCP client"
<f00b4r0>
makes sense
<neggles>
the downside to 192.168.1.1 is you can't plug a whole bunch of freshly-flashed APs into a switch and get into them
borek has joined #openwrt-devel
<neggles>
but if it's DHCP client + also 192.168.1.1 that works fine
<f00b4r0>
fwiw the patch I sent only deals with the devices that were explicitly listed in set_lan_wan. For those that use the catchall, I'm afraid that's more work than I'm willing to do :)
borek has quit []
<neggles>
Habbie: short version: as i'm sure you know, right now OpenWrt defaults to 192.168.1.1 with a DHCP server enabled and IPv6 ND/PD set up to delegate prefixes and advertise DNS, even on devices that are intended to be APs
<Habbie>
yep, aware
<Habbie>
"ask me how i know" :D
<neggles>
hahahahaha
<neggles>
same reason I do!
<neggles>
every time i flash a buildbot image onto an AP it's a race to see whether it'll break DNS for everything on my network before I turn off PD/RA/DHCP
<neggles>
(which realistically means everything gets a custom defconfig script)
<f00b4r0>
neggles: I solved this differently: I install from a direct connection to a laptop
<Habbie>
f00b4r0, i do that too but i find it tedious
<neggles>
yeah, try doing that to 50 APs :)
<f00b4r0>
:)
<Habbie>
if i had to do 50 APs today, I would probably use fe80
<jow>
+1
<jow>
or defconfig from the get-go
<Habbie>
ack
<neggles>
defconfig works great if you know how to imagebuilder or SDK
<neggles>
but, this effectively makes the buildbot images worthless for a large number of devices
<jow>
which you should if you're dealing with 50 devices
<f00b4r0>
that :)
<neggles>
since if you use that, fix the config, then factory reset it...
<neggles>
and the first couple times I didn't realize that I had to do more than just turn off DHCP server and remove the static ipv4... finding out all 3 steps required to kill the ipv6 side of things was not fun
<neggles>
IMO, these devices should be defaulting to "all ports bridged, LAN, DHCP client" because 1) that's what the OEM firmware does, 2) that's what every other accesspoint device on the market does, and (IMO) it's basically an industry standard / what people expect dumb AP devices to do
<neggles>
i've certainly heard quite a few people complain about it...
<f00b4r0>
neggles: I've done my part of the job. Feel free to submit a supplementary patch ;)
<neggles>
but removing 192.168.1.1 default static is likely to be problematic because of just how long it's been there
<f00b4r0>
meanwhile, how's that build coming along? :)
<neggles>
it's like 2/3 done
<mrkiko>
but so - it maybe time for me to understand if I am doing things right. When I want a device acting as dumb AP, I disable DHCP via ignore option of dnsmasq, stop firewall and, sometimes bridge all ports to lan, some other times not, and configure the AP to use my gateway directly in the lan network section via "option gateway" ... am I ok for IPv4? I should still understand how things are supposed
<neggles>
i should've turned off some packages i have set to m
<mrkiko>
to work in IPV6
<f00b4r0>
i should have just sent you an image :)
<neggles>
i'd propose taking a leaf out of cambium's book and using 169.254.x.y, where x and y = last 2 octets of label-mac, or 1.1 if label-mac not present, but it's probably more reasonable to use 192.168.1.1 and also have dhcp client
<neggles>
mrkiko: you need to do 3 things; set network.lan.delegate='0', set dhcp.lan.ignore=1 (or delete dhcp.lan), and del network.globals.ula_prefix
<mrkiko>
ok, missed only 2 of them :D :D
<mrkiko>
thanks
<neggles>
add_list dhcp.lan.ra_flags='none' is also a good move
<f00b4r0>
or disable ipv6 entirely :3
<neggles>
but then you lose LLMNR/mDNS
<f00b4r0>
i never bother setting up ipv6 on dumb aps
<mrkiko>
one day I will need to understand IPV6 I know :D
AtomiclyCursed has joined #openwrt-devel
<neggles>
on that note... ucidef_set_interface_lan "eth0 eth1" "dhcp" removes the 192.168.1.1 static IP, but doesn't disable the DHCP server or IPv6 RAs
<f00b4r0>
lol
<f00b4r0>
how convenient.
<f00b4r0>
now the AP can self-assign an arbitrary IP
<neggles>
well ipv4 dhcp server won't do anything because of the range mismatch, unless it's given 192.168.1.x address
<neggles>
but that won't stop the device from trying to become ipv6 default gateway and ipv6 DNS...
<neggles>
f00b4r0: image built!
<f00b4r0>
👍
<f00b4r0>
now you're going to find out it's too big to tftp boot :)
<neggles>
what's the max?
<f00b4r0>
iunno
<f00b4r0>
depends on bootloader version apparently
<mrkiko>
if I have network.lan.delegate == 0, should I also set the ra_flags or may I do one OR the other?
<mrkiko>
I know it's probably stupid question - but as you understood, IPV6 isn't a strong point for me :D
<f00b4r0>
mine happily booted a 5.3M one
<f00b4r0>
5533992 exactly
<neggles>
mrkiko: if you don't want the device to do DHCP, `uci del dhcp.lan` should do it i think
<neggles>
since ra_flags is under that
<f00b4r0>
or shutdown dnsmasq
<neggles>
f00b4r0: well this one is 7.3MiB so...
<mrkiko>
neggles: I have the ignore set for lan, so I should be ok. I was missing the delgate thing
<f00b4r0>
neggles: eww. I'd be positively surprised if it boots :)
<neggles>
i should probably have left tcpdump-mini and ethtool-full out :P but probably it won't boot anyway because of semibroken ether1
rua has quit [Quit: Leaving.]
<neggles>
f00b4r0: ok yep no netboot for me
<f00b4r0>
:)
<neggles>
not size
<neggles>
broken interface
<neggles>
routerboot sends the DHCPDISCOVERs but never acks the reply
<neggles>
flash clip it is then
<f00b4r0>
such dedication :D
<neggles>
i will not let it beat me :P
<neggles>
(they're also stupid easy to disassemble, the cover just hinges upwards)
robimarko has joined #openwrt-devel
ekathva has quit [Quit: Leaving]
<neggles>
hmm. flash clip powered up the soc.
<neggles>
but it still read and verified fine? yolo
<robimarko>
f00b4r0: Finally movement from Kalle
<f00b4r0>
robimarko: yes! And you didn't even have to insist it's a bug the driver sends the same device path for both devices :)
<robimarko>
Well, we are in the "I need to think a bit about this" phase
<robimarko>
So not there yet
<f00b4r0>
which is why the bug argument may eventually come in handy
<robimarko>
Yeah, I am saving that if its really needed
<f00b4r0>
but he grabbed it into pending. My guess is, if it doesn't break anything (and it really shouldn't), I suspect he'll let it in
<robimarko>
Cause, he may think about it but there is really no way around using proper unique naming per radio
<robimarko>
I hope so
<robimarko>
BTW, MikroTik just changed their logo
<neggles>
technically they changed it like 6 months ago, but only officially as of like a month ago
<neggles>
new one is nice
<robimarko>
Well, I dont think they had it on the website yesterday
<f00b4r0>
they didn't
<robimarko>
Kind of got used to the old one
<neggles>
they made it official in newsletter 104 or 105
<neggles>
but yeah looks like they finally did the website
<neggles>
pg9 of newsletter 105
<robimarko>
I stopped looking at those
<neggles>
then you missed out on the 4x100G switch :D
<robimarko>
Cause, otherwise I have the need to order gear that I dont actually need
<robimarko>
Havent missed on the 100G switch though, saw the product page
<neggles>
also passive desktop version of the CCR2004-16G-2S+
<neggles>
f00b4r0: flashing...
<neggles>
holding the SoC in reset with the jtag line :P
<neggles>
robimarko: fair enough - i have that problem even without the newsletters... acquired another octeon device >.>
<robimarko>
neggles: You really like to torture yourself with Octeons
<neggles>
my justficiation is, it was $40, it has two mPCIe slots and 8 antennas, and it's octeon iii so it's not the worst
<neggles>
(also it was 1:00am. i should really set up some web filtering so I can't get on ebay after midnight)
<neggles>
i think it's boot looping hmm
<robimarko>
neggles: Does NAND work on Octeon 3?
<stintel>
neggles: lol :)
<neggles>
robimarko: I believe so, yes, using the 4.14 kernel driver
<neggles>
oct3 has fpa3
<neggles>
but i dunno cause i don't have a single octiii device with nand.
<stintel>
web filtering after certain time has been on my idea list for a while :P
<neggles>
f00b4r0: hmm it is boot looping
<neggles>
not sure if my flash method was too janky or what
<neggles>
stintel: heh, sometimes the ebay things *aren't* a bad idea
<neggles>
last night's purchase was exceptionally cool and good
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<f00b4r0>
neggles: ok, I think I'll just submit. You'll always have the option to comment then
<neggles>
yeah i'm trying again :)
<neggles>
but i'd wager it's more likely this one is boned
Tapper has quit [Ping timeout: 480 seconds]
borek has joined #openwrt-devel
guidosarducci_ has joined #openwrt-devel
rua has joined #openwrt-devel
guidosarducci has quit []
T-Bone has joined #openwrt-devel
f00b4r0 has quit [Ping timeout: 480 seconds]
<neggles>
yeah, ok. this mAP-2nD is just toast
<neggles>
it's looping attempts to netboot but ether1 is broken so it's not working, and it won't boot openwrt from flash, and i think i'm just gonna harvest the flash chip and let it die
Atomicly- has joined #openwrt-devel
AtomiclyCursed has quit [Ping timeout: 480 seconds]
Atomicly- is now known as AtomiclyCursed
Tapper has joined #openwrt-devel
<neggles>
! it's alive!
<neggles>
hm, so f00b4r0's mapping here has eth0 = mikrotik ether2, and eth1 = mikrotik ether1
AtomiclyCursed has quit [Ping timeout: 480 seconds]
Guest4 has quit [Quit: SIGSEGV]
goliath_ has joined #openwrt-devel
goliath_ is now known as goliath
<mrkiko>
someone here with a fritz!box 7412 ??
borek has quit [Ping timeout: 480 seconds]
AtomiclyCursed has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
evils[m]1 has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
fpsusername[m] has joined #openwrt-devel
gnustomp[m] has joined #openwrt-devel
hexagonwin[m] has joined #openwrt-devel
John[m]12345678910 has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
nick[m]1234 has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
schmars[m] has joined #openwrt-devel
lykos153 has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
MatrixTravelerbot[m] has joined #openwrt-devel
will[m]1 has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
znullptr[m] has joined #openwrt-devel
borek has joined #openwrt-devel
<T-Bone>
neggles: correct
T-Bone is now known as f00b4r0
<neggles>
okeydokey
<f00b4r0>
neggles: should I add your Tested-by?
<neggles>
yes
<neggles>
works great
<neggles>
I forgot about the 'have to force backup booter' thing
<f00b4r0>
what should I use?
<neggles>
Tested-By: Andrew Powers-Holmes <aholmes@omnom.net>
<f00b4r0>
neggles: you shouldn't have to tho. Unless that's something specific about your device
<neggles>
tbh i was having to do that half the time with routeros
<neggles>
am now trying to work out how to edit hard_config to turn the uart back on
<f00b4r0>
ok. Sounds like your device is on its last leg then :)
<neggles>
yeah something is very broken in the switch core
<neggles>
just connecting ether1 to one of my other mikrotiks causes all traffic to halt after 15 seconds or so
<neggles>
not a clue wtf is happening there
<f00b4r0>
heh
<f00b4r0>
ok I'm git-email'ing
<f00b4r0>
sent
<neggles>
I think i worked out why the led trigger is broken and it's still not your problem; gpio gpiochip0: (18040000.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
<f00b4r0>
ha, I notice I left some copy pasta in the DTS for a node name "enable_poe_port5"
<f00b4r0>
oh well, it's not gonna hurt anyone :)
<neggles>
oop :P
<f00b4r0>
"funny" how I can read some code a gazillion time and only notice these things *after* I send patches :P
<jow>
it's like overreading that spelling mistake in the first sentence of a document over and over again
<f00b4r0>
exactly!
rua has quit [Ping timeout: 480 seconds]
<f00b4r0>
brain playing tricks
<neggles>
oh, hard_config doesn't have a crc?
<f00b4r0>
neggles: no. It's not supposed to be modified after all :)
<neggles>
bueno
<neggles>
time to change uart=no to uart=yes
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<neggles>
i literally have to flip one bit? alrighty
<f00b4r0>
yep
<robimarko>
Yeah, UART is just one bit
<neggles>
so it's 0x00694005, and i need to make it 00694004?
<neggles>
hm
<robimarko>
You need to flit the UART disable bit from 1 to 0
<neggles>
which is BIT(0)
<f00b4r0>
in /sys/firmware/mikrotik/hard_config/hw_options you will se "no UART" change from yes to no
<f00b4r0>
correct
rua has joined #openwrt-devel
<neggles>
hard_config/hw_options is read-only so I was going to read/edit/write
<f00b4r0>
yes, as I said you're not supposed to edit hard_config so I didn't write the write-side of the driver :)
<neggles>
yep i figured
<f00b4r0>
(because I follow the rules :3)
<neggles>
it'd be nice if it could flip the uart bit :P
<neggles>
bit flipped!
<neggles>
but still no uart output *shrug*
<neggles>
prolly the uart got broken by whatever broke half the rest of it. meh.
<neggles>
it's kinda funny really, this thing was working perfectly fine, then i put it in a box for 4 years and when it came out it was screwed
csrf1 has joined #openwrt-devel
<f00b4r0>
solder whiskers?
<neggles>
i can't see anything obvious
<neggles>
I upgraded it to rOS v7 (that's why i got it out of the box), and I can't say for sure whether it was misbehaving before that or not
<neggles>
should probably just toss it.
AtomiclyCursed has quit [Ping timeout: 480 seconds]
<csrf1>
if I'm rebuilding my router's uboot, how can I also include the oem radio & config partitions? Do I have to manually extract those partitions from my oem backup image, and merge them into my uboot image? if so, how do I do that? And, do I need to include the partition information in my uboot config, or in my custom kernel config?
<neggles>
csrf1: you do not touch the existing radio and factory partitions, you leave them as-is - but as for the rest of your question that's highly dependent on what device it is
<csrf1>
it's an MT7628. The OEM u-boot has serial console input disabled (the RX line doesn't work even though it's physically connected)
<csrf1>
neggles, this is why I want to re-flash uboot
<neggles>
csrf1: right. so you need to use the ralink sdk u-boot, *but*
<neggles>
can you paste a boot log?
<neggles>
you might only need to set an environment variable
<csrf1>
I used TP-link's GPL code for my router to build a u-boot image that's 4MB, but it will obviously wipe out the entire flash
<neggles>
and the uart works once you're into linux?
<csrf1>
old router with 4MB/64MB (I'm going to swap out the flash with a 16MB chip once I figure this all out)
<csrf1>
neggles, nope, doesn't work with LEDE either
<mrkiko>
csrf1: so I would check physical / electrical connection before
<neggles>
hm. are you 180% sure it's connected? ^ yeah
<neggles>
could just be pinmux settings
<mrkiko>
Pepes: are you the guy who worked on mvebu u-boot ?
<csrf1>
i get continuity 'beep' with multimeter from RX pin to UART0_RX pin on SoC, not much more i can check
<mrkiko>
Pepes: for the Turris?
<Pepes>
mrkiko: Yes, is there anything wrong?
<neggles>
csrf1: you are probably missing a pull-up resistor
<csrf1>
neggles, it's required on RX line?
<csrf1>
figured my FTDI adapter would drive it
<mrkiko>
Pepes: no, absolutely. Just wondering - if I send you a GL-MV1000, would you like to try to build a port of u-boot for that device? I would interested on it to make things overall better for the device
<mrkiko>
Pepes: I know it's a considerable amount of work...
<neggles>
csrf1: it's not uncommon for uart adapter TX to be open-collector since RX is meant to be pulled up on the other side iirc
<neggles>
normally there's either a 10K to VCC somewhere or the SoC pinmux will be configured for bias-pull-up
<csrf1>
neggles, so, how to test? power up router and see if the RX line is at Vcc or GND?
<neggles>
measure voltage from RX to GND with the board powered on
<neggles>
it should read 3.3V
<csrf1>
ok
<Pepes>
mrkiko: mrkiko: That's a generous offer, though! I think I need to apologize since I am quite busy these days. I need first to finish my bachelor's thesis and see what I will be doing next. I can not accept additional work since we need to first upstream our devices to have proper support.
<mrkiko>
Pepes: no worries. In case, you know where to find me.
<mrkiko>
Pepes: on what device are you working?
<Pepes>
mrkiko: Turris MOX and Turris 1.x to have them both supported in OpenWrt
floof58 is now known as Guest82
floof58 has joined #openwrt-devel
Guest82 has quit []
<neggles>
that's the armada 3720 one that's pretty close to the espressobin isn't it?
<mrkiko>
Pepes: great!!
<Pepes>
Yes, Armada 3720 is used in Turris MOX, but the SoC itself is really disaster. :-(
<neggles>
ah, i meant the MV1000 - but yes, it is :P
<neggles>
tplink oc200 is also a 3720
<neggles>
but with an abomination of a qca 10/100 switch attached to it
<mrkiko>
I like the mv1000 due to the form factor and - it works without issues here, even tough it seems some samples at least (can't reproduce it on mine for now), exhibit hangs when accessing SPI flash memory. Mine seems stable, but I should admit I do very little acccesses to the SPI memory if at all during runtime
<mrkiko>
with proper u-boot support yo may also decide from where to boot more easily
<mrkiko>
since the device comes with spi and mmc. but hey, for now I am using it as a NAT pppoe device, so that i can play with whatever I use as an AP
valku has joined #openwrt-devel
<neggles>
what the heck is an IPQ0518
<csrf1>
I'm trying to understand what exactly is in the radio partition for an MTK device. I read on a forum thread that it contains factory calibration data. Is this the case? How critical is this data? What happens if it's accidentally modified or deleted?
<neggles>
you lose wifi
<neggles>
but you can do a partial flash with flashrom
<csrf1>
is there anyway to approximate it with some other data? a backup from some other device?
<neggles>
well... how are you planning to flash your modified u-boot?
<csrf1>
neggles, not sure yet, but this is more of a side question; just wanted to know more about this delicate 'radio' partition
<csrf1>
so, you're saying I can do a partial flash w/ flashrom and just skip over the radio partition?
<neggles>
wiping it without a backup will effectively kill the wifi functionality permanently
<neggles>
yes, but you'd need an spi flash clip or root access to the running unit
<neggles>
and if you have either of those you can back up the whole thing
<csrf1>
I have the SPI clip
<csrf1>
I don't think I've wiped the radio partion. So far, the only things I've tried to do are flashing a LEDE image and the factory image via tftpd
<neggles>
then dump the entire flash chip with flashrom -r
<neggles>
and keep that dump somewhere safe
<csrf1>
yup, already did that, but I did it after doing the other two operations: flashed with lede image (from robimarko) and then tried to revert to factory image
<neggles>
the first rule of messing around with router firmware is "dump the entire flash and put it somewhere safe before you touch anything else"
<neggles>
if you were tftp flashing that won't have touched config/radio
<csrf1>
yes, i know *facepalm* I started drinking beer and got impatient
<csrf1>
trying to tftp the factory image caused a bootloop. it didn't accept the factory image
<neggles>
quality
<csrf1>
i had to use another procedure where I used sysupgrade
<csrf1>
now, it's back to factory, but I haven't tested wifi yet. will do that next, along with uart voltage
<neggles>
its probably just a 5018 with a QCN5122 in the same package
<robimarko>
Then its super budget
<aiyion>
can someone tell me, if the MT7610E (5GHz) of the archer c20 v4 is capable of meshing? The hardwar info says "only ap" but there have been a lot of improvements on that device in the past months and years.
<neggles>
btw can confirm the XE5-8 is IPQ8078A + 1x QCN5124 + 2x QCN5154 + 2x QCN9074
<aiyion>
"As of mid-2020 OpenWrt works with most, if not all, features."
Albert has joined #openwrt-devel
wvdakker has quit []
wvdakker has joined #openwrt-devel
csrf1 has quit [Remote host closed the connection]
ecloud_ has quit [Ping timeout: 480 seconds]
T-Bone has joined #openwrt-devel
f00b4r0 has quit [Read error: Connection reset by peer]
minimal has joined #openwrt-devel
<blocktrron>
aiyion: mesh works somewhat
ecloud_ has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
<aiyion>
blocktrron: to what limitations?
<csharper2005>
Hi again, all! One more question about Linux patches. I got feedback for 2 of 3 patches... One of them needs correction. Is it necessary to wait feedback for the remaining patch 3? or I need correct patch 1 and send updated set v4? https://lore.kernel.org/all/20220503154254.2339744-1-csharper2005@gmail.com/
<slh>
give it a ~day
csrf has joined #openwrt-devel
<csrf>
neggles, thank u very much sir...
<philipp64>
anyone know why the WiFi certified location service isn't being leveraged in more COTS APs? Intel seems to have implemented it, but... not seeing it anywhere else...
danitool has joined #openwrt-devel
russell2 has quit [Quit: leaving]
Tapper has quit [Read error: Connection reset by peer]
csharper2005 has quit [Remote host closed the connection]
borek has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
minimal has quit [Quit: Leaving]
bprfh1 has joined #openwrt-devel
bprfh1 has quit [Quit: Leaving.]
hell__ has joined #openwrt-devel
<Pepes>
mrkiko: Btw, I spoke with colleagues in the office and they told me that we already have the device which you mentioned in our office.
<hell__>
hi, so I found a working TP-Link Archer C1200(EU) V2.0, which has a Broadcom BCM47189 SoC, a BCM53125 Ethernet switch, and a BCM43217 Wi-Fi chip
<hell__>
how hard would it be to get OpenWRT running on it? I'm aware that Wi-Fi support will be awful because Broadcom
<slh>
hell__: forget it, BCM43217 is a softmac chip
<hell__>
slh: so no drivers for that chip. what about the rest of the thing? looks like the main SoC also integrates a Wi-Fi radio
<hell__>
I think the Tenda AC9 has the same BCM47189 SoC, and there seems to be experimental support for it
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
Tapper has joined #openwrt-devel
<hell__>
even if Wi-Fi won't work properly, how would I try to port this router?
<mrkiko>
Pepes: :) :)
<mrkiko>
Pepes: that said, I should note the flash layout doesn't seem quite right for this device
<mrkiko>
Pepes: in the sense - that partitions are not ending in write-boundary or block, and that sound strange. But I may very well be wrong.
srslypascal is now known as Guest115
srslypascal has joined #openwrt-devel
Guest115 has quit [Ping timeout: 480 seconds]
valku has quit [Quit: valku]
Borromini has joined #openwrt-devel
valku has joined #openwrt-devel
<hell__>
why do bcm53xx targets have no .dts files?
<hauke>
hell__: the dts files are mostly in the upstream kernel and OpenWrt has some patches
<hell__>
alright
<hell__>
so far, to try building openwrt for the Archer C1200, I've only added an entry for it in target/linux/bcm53xx/image/Makefile
<hell__>
the Tenda AC9 (which I'm using as reference because it has the same chips) doesn't seem to have many specific stuff
<hell__>
much*
<hell__>
or I suck at grepping
<Borromini>
git grep should turn up anything there is
<hell__>
ah, there's a kernel patch that touches a .dts file
<hell__>
(compiling noises)
<hell__>
hrm,
<hell__>
I'm looking through vendor GPL dump and looks like the linux kernel version is too old to have a devicetree
<hell__>
2.6.36
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
* stintel
is loving the FIDO2 ssh key support in dropbear
MAbeeTT3 has joined #openwrt-devel
<olmari>
Noice
<stintel>
now if only Solo can fix their resident key support I can retire my yubikeys
MAbeeTT2 has quit [Ping timeout: 480 seconds]
Slimey has quit [Read error: Connection reset by peer]
bprfh has quit [Quit: Leaving.]
<hell__>
ok, now I need to figure out how to tell linux about the dtb
Slimey has joined #openwrt-devel
bprfh has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<hell__>
hmmm, the build system tries to generate files for tenda_ac9 even though I've selected the c1200 option I added
bprfh has quit [Quit: Leaving.]
<hell__>
now I get errors because tplink-safeloader doesn't know about my device
<hell__>
ok, I found the things I should add to support_list, now I need to figure out the rest
<hell__>
I guess I can get the partition layout from OS
<hell__>
do I need tplink-safeloader if I'm trying to boot a ramdisk image?
robimarko has quit [Quit: Leaving]
* hell__
gives up
cbeznea has quit [Quit: Leaving.]
dedeckeh has quit [Remote host closed the connection]
<hell__>
I guess I'm too tired to figure out what I'm doing wrong
philipp64 has quit [Quit: philipp64]
<Grommish>
I've got LLVM libs in STAGING_DIR_HOST/llvm-rust/lib and I need to either put them in the build-root path, or symlink them to STAGING_DIR_HOST/lib. Any suggestions on how best to go about doing it? I get a "error while loading shared libraries: libLLVM-14.so: cannot open shared object file: No such file or directory" error without it and front-loading LD_LIBRARY_PATH each time seems not the right way
<jow>
Grommish: the golden solution would be to build it in a way that the intermediate llvm-rust directory is not used/expected
<jow>
other solutoons that come to bind are patching the RPATH (ugly) or wrapping the executables (see scripts/bundle-libraries.sh)