<Ansuel> ipbuf, iface->name, iface->ifname
<Ansuel> why give 2 name?
<Ansuel> maybe test(testbr) ?
<stintel> exactly, the first one is from uci
<Ansuel> lan(br-lan) ?
<stintel> I would either completely drop iface->name from the error message or add it in the end explicitly mentioning it's from UCI
<stintel> I'm leaning towards dropping completely
<Ansuel> so ifname and nothing more
<stintel> yes, because the strerror(errno) comes from sendmsg, and UCI interface name adds no valuable info there
<stintel> only confusion
<Ansuel> Failed to send to ff02::1%testbr (Address not available)
<stintel> I've been looking at similar errors: https://github.com/openwrt/packages/pull/19218#issuecomment-1387318855
<Ansuel> Wed Mar 15 01:07:41 2023 daemon.notice odhcpd[6011]: Sending a RA on test
<Ansuel> Wed Mar 15 01:07:41 2023 daemon.err odhcpd[6011]: Failed to send to ff02::1%testbr (Address not available)
<stintel> ping6 ff02::1
<stintel> ping6: Warning: IPv6 link-local address on ICMP datagram socket may require ifname or scope-id => use: address%<ifname|scope-id>
<stintel> so yes, that seems like the correct format to me
<Ansuel> isn't it wrong that RA is sent with addr not available?
<Ansuel> btw in the code iface->name is used for normal LOG_NOTICE stuff
<stintel> well...
<Ansuel> soooo it's either we change everywhere or we use name
<stintel> ff02::1 is all nodes
<stintel> I think if the errno or %m (strerror(errno)) comes from something like sendmsg, adding iface->name (the uci interface name) adds no value
<stintel> we could use dedeckeh in here right now :)
<stintel> Additional errors may be generated and returned from the underlying protocol
<stintel> modules; see their respective manual pages.
<stintel> I'm trying to figure out what the respective manual page is in this case
<stintel> also is it #define EADDRNOTAVAIL 99 /* Cannot assign requested address */
<Ansuel> Wed Mar 15 01:17:26 2023 daemon.err odhcpd[7235]: Error sending a RA to test
<stintel> lol
<Ansuel> can't be that right?
bookworm_ has joined #openwrt-devel
bookworm has quit [Read error: Connection reset by peer]
<stintel> on this device I only saw the address not available and network unreachable during boot, restarting odhcpd now does not produce those messages
<Ansuel> what if you restart the interface?
<stintel> ifdown lan; /etc/init.d/odhcpd restart; ifup lan
<stintel> only after the last one I get: Wed Mar 15 00:25:16 2023 daemon.err odhcpd[11276]: Failed to send to ff02::1%lan@br-lan (Network unreachable)
<stintel> and then Wed Mar 15 00:25:18 2023 daemon.err odhcpd[11276]: Failed to send to fe80::1cf2:f367:9f1f:b4ff%lan@br-lan (Address not available)
<stintel> fun stuff :)
<stintel> but I'd blame it on a race condition during boot / interface bringup / ...
<Ansuel> yep in my trash setup tho it gets spammed a lot
<stintel> if it's flooding your logs, you have a misconfig
<Ansuel> i mean it's really a second bridge with ra enabled and ipv6 assign set to 64
<Ansuel> ra and dhcpv6 to server *
<stintel> maybe we could inhibit sending RA when ifstatus up == false
<Ansuel> mhhh imho the problem is somewhere else
<Ansuel> also any idea how to check if it's really a misconfiguration ?
<stintel> how did you make it spam the log ?
<Ansuel> 1. created bridge testbr 2. assigned 2 lan port 3. created interface test 4. assigned testbr to test interface 5. 64 ipv6 assign 6. ra and dhcpdv6 set to server
<Ansuel> it's not spam but it's just the RA that is failing every few minutes
<Ansuel> Wed Mar 15 01:37:42 2023 daemon.warn odhcpd[7235]: No default route present, overriding ra_lifetime!
<Ansuel> Wed Mar 15 01:37:42 2023 daemon.debug odhcpd[7235]: Using a RA lifetime of 0 seconds on test
<Ansuel> Wed Mar 15 01:37:42 2023 daemon.err odhcpd[7235]: Failed to send to ff02::1%testbr (Address not available)
<Ansuel> Wed Mar 15 01:37:42 2023 daemon.notice odhcpd[7235]: Sending a RA on test
<Ansuel> Wed Mar 15 01:37:42 2023 daemon.err odhcpd[7235]: Error sending a RA to test
djfe_ has joined #openwrt-devel
<Ansuel> oh wait i have this
<Ansuel> nope just that in log
djfe has quit [Ping timeout: 480 seconds]
<stintel> so far I cannot make it flood my log
<Ansuel> the port are up or down ?
<stintel> well up
<stintel> but if bringing the port down is what causes it then we should inhibit trying to send the packet if the port is down because trying to do that doesn't make a lot of sense?
<stintel> and if I bring lan down: Wed Mar 15 00:46:21 2023 daemon.err odhcpd[2340]: Failed to send to ff02::1%lan@br-lan (Bad file descriptor)
<stintel> Ansuel: are you using a DSA or non-DSA device ?
<Ansuel> this is non-DSA
<stintel> ok, here it's DSA
<Ansuel> let me test connecting one port
<Ansuel> i'm curious
<stintel> I suspect this might be some corner case again
<Ansuel> well that just fixed it!
<Ansuel> the error is if nothing is connected to the bridge
<Ansuel> ok
<Ansuel> disconnecting the port
<Ansuel> and i have the error again
<stintel> does ip link show something different when cable is plugged / unplugged ?
<stintel> for testbr ?
<Ansuel> this is log
<Ansuel> wait a sec for ip l
<stintel> oof my CI ran and firefox got updated, browser says no :D
<stintel> yeah NO-CARRIER
<stintel> I don't have that on DSA when unplugging all cables
<Ansuel> yep
<Ansuel> can you test by setting the port down
<Ansuel> with ip link set down ?
<stintel> br-lan or lan1 lan2 ?
<Ansuel> the port
<Ansuel> then restart the interface
<stintel> "restart the interface" -> ifup lan ? (or test in your case?)
<stintel> or what
<Ansuel> yes ifup lan
<Ansuel> i mean i think the problem here is NO-CARRIER
<stintel> I'm trying, but br-lan does not show NO-CARRIER
<stintel> actually I need to "ip link set dev lan1 up" to get NO-CARRIER on lan1
<Ansuel> ip link set lan1 carrier off ?
<Ansuel> is supported?
<stintel> 21: br-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
<stintel> hmmmz
<stintel> for some reason the wifi interface kept coming up after running wifi down
<stintel> but now even with br-lan NO-CARRIER I do not see the message
<Ansuel> with no carrier ifdown and ifup
<stintel> ufff I give up for today
<Ansuel> and i have the error again
<Ansuel> understandable ahahaha
<stintel> my home automation just hinted at going to bed ;)
<stintel> (switches off all lights at 0300)
<Ansuel> anyway i think RA should not be tried on no carrier
<Ansuel> no sense to RA to nothing
<stintel> exactly
<Ansuel> you don't have on dsa
<stintel> but :P
<Ansuel> since they are never down
<stintel> "up": true,
<stintel> from ifstatus lan when br-lan shows NO-CARRIER
<Ansuel> port may be up but with nothing connected
xes has quit [Ping timeout: 480 seconds]
xes has joined #openwrt-devel
<Ansuel> well think i will continue this tomorrow gn
<stintel> if (flags & IFF_UP && !(flags & IFF_RUNNING))
<stintel> print_string(PRINT_ANY, NULL,
<stintel> flags ? "%s," : "%s", "NO-CARRIER");
<Ansuel> where is this?
<stintel> ip/ipaddress.c from iproute2
<stintel> I think we're on to somethign
<Ansuel> yep
ptudor has quit [Ping timeout: 480 seconds]
<Ansuel> maybe something to fix in odhcpd netlink ?
<stintel> the only function in odhcpd that calls sendmsg is odhcpd_send
<stintel> just add a check there for IFF_RUNNING, if no, return
<stintel> as early as possible
<Ansuel> would love to prevent sending RA with no carrier
goliath has quit [Quit: SIGSEGV]
<Ansuel> but i think that require some execpected work
<stintel> looks like it might be easy
<stintel> odhcpd_send returns ssize_t but the return value is only really used in 1 case
<Ansuel> my idea is that the RA timer is rearmed reacting to a netdeve event
<stintel> src/router.c: if (odhcpd_send(iface->router_event.uloop.fd, &dest, iov, ARRAY_SIZE(iov), iface) > 0)
<stintel> so it could be as simple as https://gist.github.com/96755270397d79d548032847dd0ae6c9
<stintel> this is of course totally untested ;)
ptudor has joined #openwrt-devel
<Ansuel> yep should work but i would really hate the timer to run returning 0
<stintel> show me what you're talking about?
<Ansuel> when an interface change the state propagate some events... ideally we should use that to correctly trigger an interface when it does have carrier and RA can be used
<Ansuel> (overkill for this corner case i know)
<Ansuel> actually tho we already use that in the netlink file so it should be possible
<Ansuel> also dhcpv6-ia use it
<Ansuel> it's used for NETEV_ADDR6LIST_CHANGE
<stintel> send_reconf doesn't use it
<stintel> ehr
<stintel> send_reconf does return odhcpd_send
<stintel> but send_reconf callers ignore the retval
<stintel> and the only other function that looks at the retval is send_router_advert
<stintel> which increases a counter
<Ansuel> but these missing check should still cause the error in theory
<Ansuel> aka not stopping RA from start
<Ansuel> ok nice
<Ansuel> carrier change emits
<Ansuel> RTM_NEWLINK
<Ansuel> we can dynamicaly set the timer for RA
<Ansuel> based on that
<Ansuel> and we have RTM_DELROUTE to detect when carrier goes down
<stintel> ok I lost you ;)
<stintel> really time for bed
<stintel> in any case, good debugging session ;)
<stintel> nn
<Ansuel> yep solution might be easier since we already have the base anyway thanks for telling me to search for a better solution
<Ansuel> gn
<stintel> I was quite convinced that just hiding the message wasn't the best solution
<stintel> but cc dedeckeh if you come up with something?
<stintel> after cyrusff (iirc) went MIA, I think Hans is most familiar with the odhcpd code
lemmi has quit [Remote host closed the connection]
djfe_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
lemmi has joined #openwrt-devel
<stintel> Ansuel: feel free to cherry-pick e448b9bee9caca69065e4d0376dd2be747e6ab7a - alternatively come up with a better commit message for the revert
<Ansuel> where is this commit?
<stintel> odhcpd.git
<Ansuel> yes i will
dev1ce has joined #openwrt-devel
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
djfe has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
minimal has quit [Quit: Leaving]
PtitGNU has quit [Read error: Connection reset by peer]
PtitGNU has joined #openwrt-devel
SlimeyX has quit [Remote host closed the connection]
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
tomn has quit [Remote host closed the connection]
tomn has joined #openwrt-devel
max_ has joined #openwrt-devel
max_ has quit [Read error: Connection reset by peer]
ctdvqgg445[m] has quit [Quit: Bridge terminating on SIGTERM]
mkg20001 has quit [Quit: Bridge terminating on SIGTERM]
pavlix has quit []
fieryeagle954[m] has quit [Quit: Bridge terminating on SIGTERM]
fpsusername[m] has quit [Quit: Bridge terminating on SIGTERM]
ysc3839 has quit [Quit: Bridge terminating on SIGTERM]
magnusk[m] has quit [Quit: Bridge terminating on SIGTERM]
tohojo has quit [Quit: Bridge terminating on SIGTERM]
barhom has quit [Quit: Bridge terminating on SIGTERM]
schmars[m] has quit [Quit: Bridge terminating on SIGTERM]
JuniorJPDJ has quit [Quit: Bridge terminating on SIGTERM]
John[m]12345 has quit [Quit: Bridge terminating on SIGTERM]
aparcar[m] has quit [Quit: Bridge terminating on SIGTERM]
oliv3r[m] has quit []
t4h4[m] has quit []
gnustomp[m] has quit []
bluse-blue[m] has quit [Quit: Bridge terminating on SIGTERM]
Movedtomkg20001mkg20001io[m] has quit [Quit: Bridge terminating on SIGTERM]
hexagonwin[m] has quit [Quit: Bridge terminating on SIGTERM]
evils[m] has quit [Write error: connection closed]
will[m] has quit [Write error: connection closed]
vulpes2[m] has quit [Write error: connection closed]
olmari has quit [Write error: connection closed]
nick[m]12 has quit [Write error: connection closed]
whatevs111[m] has quit [Quit: Bridge terminating on SIGTERM]
JulianGro[m] has quit [Quit: Bridge terminating on SIGTERM]
omni has quit [Max SendQ exceeded]
omni has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
goliath has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
gladiac is now known as Guest7789
Guest7789 has quit [Read error: Connection reset by peer]
gladiac has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Tapper has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
robimarko has joined #openwrt-devel
guidosarducci_ has quit [Ping timeout: 480 seconds]
guidosarducci has joined #openwrt-devel
srslypascal has joined #openwrt-devel
<stintel> overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
<stintel> oops
<stintel> /dev/loop0 on /overlay type ext4 (rw,noatime)
* stintel confused
<PaulFertser> stintel: it probably has offset there for the loop device.
<PaulFertser> stintel: on x86 OpenWrt uses same essentially partition for rootfs and rootfs_data, but the latter is accessed via a loop device with offset.
<stintel> it's not x86
<stintel> my confusion is overlay being ext4 instead of f2fs
<PaulFertser> Ah, ok. IIRC there was some logic about what size of partition should use what filesystem.
agjhmk has joined #openwrt-devel
<stintel> yes, but that's jffs2 vs f2fs iirc
tomn has quit [Read error: Connection reset by peer]
tomn has joined #openwrt-devel
<PaulFertser> stintel: https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/common.c;h=e5b7bc38c2ebf297ad2ec5ec05605a497950ac0b;hb=HEAD#l166
<PaulFertser> stintel: jffs2 can be used only on mtd devices.
<agjhmk> Hello, I don't expect to get an accurate date or anything and not to be rude, but is there an estimate for the release of version 23.xx? I am waiting for explicitly the changes from commit 802df0987328246a405b9183b92b7ac94838e8e2
<aparcar[m]> Any OpenWrt people at embedded world?
<PaulFertser> stintel: apparently f2fs would be used if there were more than 100 MiB of space for the overlay.
<stintel> this I knew. but I thought the alternative was jffs2
<stintel> TIL
<stintel> thanks
<PaulFertser> agjhmk: my suggestion would be for you to not wait and instead just grab this patch and apply to your current tree.
<PaulFertser> stintel: yeah, it's not x86 specific it's just mtd vs block device.
<stintel> or ask for it to be backported to 22.03
<agjhmk> stintel: If I backport it myself, where would I create a pull-request-equivalent?
<PaulFertser> Mailing list accepts regular patches and pull requests too.
<PaulFertser> Probably "github pull requests" for release branches can be submitted as well.
<stintel> agjhmk: this is already part of 22.03
<stintel> or my coffee doesn't work yet
Borromini has joined #openwrt-devel
<robimarko> Yeah, its already in 22.03
<agjhmk> stintel: Oh wow, yea you're right. I am having some issues recognizing my Meiglink SLM750 modem though
<agjhmk> stintel: thanks! I will look further into it why the modem isn't recognized then
<stintel> welcome, and good luck :)
<dwfreed> it's of course always within the realm of possibility that the backported patch is broken for whatever reason
agjhmk has quit [Remote host closed the connection]
<dwfreed> RIP
<Borromini> am I overlooking the 23.xx status page on the wiki?
<Borromini> I thought there was some
<Borromini> https://openwrt.org/docs/guide-developer/releases/goals/23.xx is there but void of all meaning so far.
<robimarko> Check out the last meeting notes
<Borromini> thanks
<Borromini> that somehow didn't pop up when searching the site for 23.xx
<Borromini> robimarko: sorry, I meant entering it as a search term didn't make it pop up, I did have the link :)
<Borromini> posted to the ML as well, thanks
cbeznea has quit [Remote host closed the connection]
cbeznea has joined #openwrt-devel
<mrkiko> would be nice to be able to upstream ./target/linux/generic/hack-5.15/780-usb-net-MeigLink_modem_support.patch - it would need to be splitted in two patches definitely. But one needs the hardware to test full correctness and maybe then a diferent match type might be suggested for the qmi_wwan.c part
dangole_ has joined #openwrt-devel
agjhmk has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
Borromini has left #openwrt-devel [#openwrt-devel]
agjhmk has quit [Remote host closed the connection]
agjhmk has joined #openwrt-devel
<agjhmk> mrkiko: I have a teltonika rut955 device with a meiglink SLM750 modem equipped at hand so I am already testing the patch.
<mrkiko> agjhmk: great!
<agjhmk> It seems that there are some oddities when registering... I have a somewhat interesting dmesg snippet, should I just post it here? I'm somewhat new to irc-chat/culture
<mrkiko> agjhmk: well, use a pstebin somewhere, I use ix.io but there are many to choose from
<mrkiko> slh: hi!!
<dwfreed> generally anything longer than 3 lines is best in a pastebin
<agjhmk> mrkiko: That's a nice website. I will bookmark that :) Here's my dmesg: http://ix.io/4qSq It seems that the device is recognized and then disconnects immediately after.
<karlp> if it keeps cycling like that, that can be lack of power
<karlp> my modem will do that if I'm paying off a usb cable instead of it's own supply.
<agjhmk> karlp: the modem soldered onto the motherboard, so I dont expect it to be a power-issue. It also only happens once at startup, so I dont think it's that.
<karlp> ok, fair enough, mine's soldered down too, but I cna powr by my device multiple ways, and one of them will result in the modem turning on and off, and seeing those 4 qmi tty's created and torn down over and over.
<agjhmk> odd. Is that a meiglink modem as well?
<karlp> no, a quacktel, it was just an idea, I'd see that sort of thing before, if it's not happening for you, no problem :)
<agjhmk> karlp: okay fair :) It might actually be an issue with the hardware itself, since it is a device that we got back from a customer complaining about issues with the tele-connection. I might doublecheck some time in the future, but for now we'll just replace the device with a quectel ec25-eu device of which we have a working setup
<stintel> heh quacktel :P
<stintel> does that mean you don't like them ;)
<robimarko> Who likes any modem manufacturer
<karlp> ^^
<stintel> I guess I haven't used modems long enough :)
<karlp> using is ... probably all somewhat ok, but purchasing them is a trainwreck.
<karlp> though using them with uqmi seems to be somewhat problematic as well :)
<stintel> gaaaahhhh macOS is such trash
<stintel> % ls /Applications | grep -c Xcode --> 11
<stintel> no wonder I have no storage left
<stintel> they know everything better than you yet they cannot remove Xcode that is not compatible with your shiny new macOS version
<agjhmk> I just completely avoid Xcode and use homebrew packages for everything
<stintel> I usually completely avoid macOS but my current task at work requires me to use it
<stintel> also it's brew that is complaining that Xcode is missing :P
barhom has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
ctdvqgg445[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
dfceaef[m] has joined #openwrt-devel
domon has joined #openwrt-devel
evils[m] 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]1234567 has joined #openwrt-devel
JulianGro[m] has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
magnusk[m] has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
nick[m]12 has joined #openwrt-devel
oliv3r[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
schmars[m] has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
tohojo has joined #openwrt-devel
MatrixTravelerbot[m]1 has joined #openwrt-devel
vulpes2[m] has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
will[m] has joined #openwrt-devel
ysc3839 has joined #openwrt-devel
znullptr[m] has joined #openwrt-devel
<stintel> my goodness brew still complains
<stintel> it's using Xcode 13.1.0 from fucking .Trash
<stintel> what absolute garbage OS is this
<agjhmk> oh wow.
hcshmk has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
<hcshmk> Hi, does the network node in uci (or /etc/config/network) have an equivalent of post_up? I'm having trouble manually changing the netmask and broadcast address of a qmi interface.
<xback> robimarko: Latest version, .. and everything seems to work. any comments from your side? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=cd165effd6d57fe19fb39c04f5acc9401882d6b4
<xback> robimarko: please let me know if it's ok to have you assigned still as original developer, unless you don't want anything to do with Wallys ;-)
<robimarko> Sure, that is fine
<robimarko> I would suggest moving to NVMEM for caldata
<xback> i'll need to lookin to that .. no expecience with nvmem yet atm
<mrkiko> agjhmk: so, the initial switch might depend on the modem executing some code changing usb compositions or so
<mrkiko> agjhmk: but then, you might observe this on other samples as well
<robimarko> xback: There is a lot of examples in ipq40xx
<robimarko> Also, please use the existing labels for mdio, rng, usb, etc
<mrkiko> karlp: did you get autoconnect working ?
<mrkiko> I however am in the impression we'll need to jump to ModemManager for this kind of devices
<mrkiko> MM maybe too big with it's dependencies, but these modems are too complex
<agjhmk> mrkiko: yea, I figured that might be the case, but I dont know how I would debug a usb-device that is explicitly disconnecting itself...
<mrkiko> agjhmk: so - it disconnects then connect back, and then works? Or does it disconnect again from time to time?
<robimarko> That smells like a modem FW issue
<agjhmk> mrkiko: It just stays disconnected.
<mrkiko> ok, it disconnect but in the dmesg it seems it enters in diagnostic mode
<mrkiko> i.e.: you end up with only a single serial port, the device is not disconnected totally
<agjhmk> robimarko: That might very well be the case. I have sniffed at updating the firmware of other modems (quacktel EC25-EU to be specific), so if meiglink firmware update process is similar, then it might fix the issue. However, I dont know how I should talk to the device when it is disconnected
<mrkiko> agjhmk: or am I misreading the dmesg?
<agjhmk> mrkiko: a quick 'ls /dev/ttyUSB*' unveils that ttyUSB0 exists - I tried to open it in picocom and talk AT-commands (not sure if meiglink supports that though) but to no avail
<mrkiko> agjhmk: no, it might be in the bootloader or diag modeor whatever, and qmi-firmware-update from libqmi might support that as you righly pointed out
<mrkiko> agjhmk: that said, the reason why this happens needs to be investigated. It might happen due to the modem having problems bringing up itself for e.g.: too many too frequent power cuts
<mrkiko> (yes, these devices can be bricked that way also)
<agjhmk> mrkiko: dont scare me like that man
<agjhmk> mrkiko: when you say "frequent", are we talking frequencies in seconds, or would say, once every ten minutes be okay?
<mrkiko> agjhmk: I'm talking of "fast enough to prevent the modem from fully initializing" ...
<mrkiko> agjhmk: so probably in the matter of seconds.
<mrkiko> agjhmk: these devices can do impressive stuff but in system design perspective they might leave something to be desired at times
<agjhmk> mrkiko: okay, then we should be fine. We might cut power from our devices somewhat frequently, but it's in the 5-10 minute range at most
<mrkiko> agjhmk: not, should be not enough to "cause" so many issues. But in my experience I've seen at least the linux part of these modems stays with writeable filesystems and when power goes down there is no way to umount. This shouldn't be a problem still because in general no writes should happen so frequently. But I know of cases where after aggressive powercycles in seconds range caued the device to
<mrkiko> not come up anymore
<agjhmk> mrkiko: damn. I'll keep that in mind!
<agjhmk> mrkiko: I might try to fiddle the firmware though. Maybe I can get it talking through that ttyUSB0
<mrkiko> agjhmk: sure you can, but then I'm at all not expert in firmware updating and such, you might head to #modemmanager in libera in case to try to get some help in there
<mrkiko> agjhmk: and in any case, if you can give more power budget to the modem, do so. These devices have in my opinion very varying power consumption figures, of course network conditions dependent.
<karlp> mrkiko: I never got uqmi to work with my quectel eg91, modem manager worked first go, so...
<mrkiko> karlp: got it.
<agjhmk> mrkiko: I assume teltonika have wired the modem to the electrical specification. But you never know with those guys...
<karlp> I'm not sure they're more complicated, I just don't think uqmi is documented enough for anyone else to contribute to, and not used enough to have enough in it already..
<mrkiko> agjhmk: well, maybe they did their job at best but the modem didn't like network conditions or rebooted for some other reasons. Remember when my ONDA MT8205 (mdm9200 if I'm right) rebooted itself even when I connected it with an Y-cable to my Desktop pc... :D
<agjhmk> mrkiko: damn.
<karlp> quectel eg91 manual requests _min_ 2A on 3v8, so even a Y cable won't always work :)
<mrkiko> karlp: :D
<karlp> it's "network and conditions dependent" how much it really needs, but still...
<hcshmk> I'm getting the following message in syslog, should I be concerned? It happens during network interface restart event. daemon.notice netifd: wwan (3288): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wwan" } (Permission denied)
<mrkiko> Well, I've been lucky so far - most of the 4G / 3G modems I tried worked fine in general. But (my 2 cents only) handling modern ones without a good abstraction layer ... can be problematic. But I have zero experience with the Qualcomm software itself
xback has quit [Ping timeout: 480 seconds]
xback has joined #openwrt-devel
<xback> robimarko: 1 question left
<xback> robimarko: in your intial DTS i noticed this for NAND: reg = <0x00000000 0x04000000>;
<xback> robimarko: while from wally it's this: reg = <0x00000000 0x08000000>;
<xback> the flash itself is 128M
<f00b4r0> stintel: the garbage is brew, not the OS.
<xback> any reason it's limited to 64M (0x04000000) ?
<f00b4r0> but you're welcome to feed your prejudices ;)
<robimarko> xback: Cause they were mix and matching bootloaders
<robimarko> And most of them had the stock table set for 64M
<hcshmk> mrkiko: do you by any chance know if one can override the ipv4 information reported by `uqmi --get-current-settings`? Something akin to `uqmi --set-current-settings` would've been great, but that doesn't exist. Our ISP has a misconfigured dhcp server, and I'm trying to remedy the issue.
mcbridematt has quit [Remote host closed the connection]
<stintel> f00b4r0: the OS is *still* emptying trash as we speak.
<stintel> I have no words
<mrkiko> hcshmk: sorry, I don't understand your question
<hcshmk> mrkiko: sorry, let me rephrase. Do you know if it is possible to override the automatically discovered ipv4 settings on eg. a quectel modem?
<f00b4r0> stintel: I don't know what to say ;)
<stintel> f00b4r0: me neither
agjhmk has quit [Quit: Page closed]
<mrkiko> hcshmk: I don't think so
<hcshmk> mrkiko: alright thanks
<mrkiko> hcshmk: you might have better luck playing after the modem; furthermore, do you have the same issue with different modems? I don't know if DHCP is implemented in firmware or at a network level
<hcshmk> mrkiko: I'm working on the same devices as agjhmk, so I'm dealing with Quectel EC25-EU on a Teltonika RUT955. I guess I'll just use a hotplug script listening for dhcp change events then? Or do you know any nifty ways to change ipv4 addr stuff more cleanly?
<hcshmk> mrkiko: I haven't tried any other modems, to answer your question. I'm not keen on dealing with dhcp either, I'd just like to manually change broadcast, netmask and default route.
soxrok2212_ has quit [Quit: Who ate my gummy worms?]
soxrok2212 has joined #openwrt-devel
dansan has quit [Ping timeout: 480 seconds]
Lynx- has joined #openwrt-devel
minimal has joined #openwrt-devel
<karlp> I mean, it's "just" an other interface, but whether you can pick your own is goign to heavily depend on what the network wants to do?
hcshmk_ has joined #openwrt-devel
hcshmk has quit [Read error: Connection reset by peer]
<hcshmk_> I've found that the easiest way for me to solve the problem is to add a 'force_netmask' and 'force_broadcast' option to the qmi config format in uci, then conditionally apply in qmi.sh at line ~420
<mrkiko> hcshmk_: sorry - I have no better ideas... but it's pretty strange the modem doesn't return correct datq
<mrkiko> *data*
<hcshmk_> The ISP I'm working with is a tiny shop of only a handful of people. Their setup (ISP-side) is just misconfigured, that's all.
<mrkiko> hcshmk_: interesting and creative scenario!! :)
<mrkiko> hcshmk_: out of curiosity, how do you deal with autoreconnect?
<hcshmk_> mrkiko: I'm not quite sure, to be honest. I haven't really thought about it? Our modems seem to handle reconnects just fine, so I'm guessing uci set network.wwan.autoconnect=1 is enough.
<mrkiko> hcshmk_: thanks
Lynx- has quit [Ping timeout: 480 seconds]
hcshmk_ has left #openwrt-devel [Leaving]
dangole has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
xback has quit [Ping timeout: 480 seconds]
gladiac is now known as Guest7860
gladiac has joined #openwrt-devel
srslypascal is now known as Guest7861
srslypascal has joined #openwrt-devel
cbeznea1 has joined #openwrt-devel
Guest7860 has quit [Ping timeout: 480 seconds]
cbeznea has quit [Ping timeout: 480 seconds]
Guest7861 has quit [Ping timeout: 480 seconds]
* f00b4r0 curses. 2 DIMMS pass memtest separately; fail when they are together in dual channel.
<stintel> :(
<stintel> now chrome doesn't even work anymore
cbeznea has joined #openwrt-devel
cbeznea1 has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m]1 has quit []
dfceaef[m] has quit [Quit: Client limit exceeded: 20000]
Q__ has quit [Quit: Client limit exceeded: 20000]
magnusk[m] has quit [Quit: Client limit exceeded: 20000]
tohojo has quit [Quit: Client limit exceeded: 20000]
xback has joined #openwrt-devel
<f00b4r0> stintel: your Mac hates you I'm afraid. HAL9000 style ;)
ctdvqgg445[m] has quit [Quit: Client limit exceeded: 20000]
Movedtomkg20001mkg20001io[m] has quit [Quit: Client limit exceeded: 20000]
mkg20001 has quit [Quit: Client limit exceeded: 20000]
dansan has joined #openwrt-devel
nwf has quit [Ping timeout: 480 seconds]
hanetzer3 has joined #openwrt-devel
nwf has joined #openwrt-devel
hanetzer2 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Ansuel> stintel hello again.... btw yesterday i created a solution but i'm still not sure...
<Ansuel> the confusing part is that once the interface has carrier one time the thing doesn't fail anymore till you restart the interface
<Ansuel> so now i need to compare the values set before and after
hanetzer4 has joined #openwrt-devel
hanetzer3 has quit [Ping timeout: 480 seconds]
nwf has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
paper_ has quit [Quit: WeeChat 3.8]
paper_ has joined #openwrt-devel
paper_ has quit []
paper_ has joined #openwrt-devel
paper_ has quit [Quit: WeeChat 3.8]
paper_ has joined #openwrt-devel
nwf has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Gramdalf has joined #openwrt-devel
<Gramdalf> Hallo there! I'm in the process of building a custom image (using the image builder from docker), and I'm curious if there's a way to double check that it isn't too big.
<Gramdalf> Building for the linksys ea8500, it has 128mb flash. As far as
<Gramdalf> I can tell the image should only build if it's small enough, but I'm not sure if that only applies to compiling everything from source, or if it works with the image builder as well
<Gramdalf> My final .bin file is 76mb, so I'm hoping it should be fine... I'm just not sure.
<Ansuel> also check if the device have dual firmware
<slh> it does
<Gramdalf> Yeah, let me link the toh entry
<slh> maximum image size would be under 40 MB (4 MB kernel + 36 MB rootfs, I assume that quite a bit is going into ECC as well)
<slh> in other words, you need to halve your image size somehow
<Gramdalf> yeah, 40mb is what the toh says
<Gramdalf> I know how I can do it I think, let me lay out my thought process.
<Ansuel> Linksys configuration
<Ansuel> 32.5 MiB
<Ansuel> sad
<Ansuel> Gramdalf extroot may be an idea tho
<Gramdalf> The majority of the space is taken up by gcc and python3.10 - I'm running klipperWRT
<Ansuel> o.O
<Ansuel> probably gcc is the main culprit
<Gramdalf> I will do that for some parts - I'd prefer if the base router could be entirely on flash, but only klipper on a USB stick
<Gramdalf> so rather than extroot, I've identified where the files are stored, so I can mount an external drive somewhere and have symlinks for the big stuff (gcc/python)
<Gramdalf> Yeah, gcc is 100mb uncompressed, python is 97mb
<Gramdalf> Would the system be able to follow symlinks? Or should I just install gcc/python with opkg and specify a different location
<Gramdalf> with opkg --dest
<Gramdalf> I suppose that's another thing - if everything in the image builder is in the squashfs partition, wouldn't it be too big? squashfs as according to the toh is only 2mb
<PaulFertser> squashfs just needs to fit the flash, the size is dynamiic.
<Gramdalf> ic, makes sense
<PaulFertser> Gramdalf: usually if sysupgrade file is generated it means the build system checked its size.
<PaulFertser> It's all in the image/Makefile
<Gramdalf> sudo docker run -v "$(pwd)"/bin/:/home/build/openwrt/bin -it --rm openwrtorg/imagebuilder:ipq806x-generic-22.03.3
<Gramdalf> Using that docker image
<Gramdalf> PaulFertser which preincludes the makefile. But i'm not sure if the sysupgrade limit applies to only building the image from source, rather than taking prebuild packages
<Gramdalf> *prebuilt
gladiac has quit [Quit: k thx bye]
Lynx- has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
<Gramdalf> Hmm looks like I can use a symlink if I opkg install gcc --force-space
<Gramdalf> Mount a usb drive at /mnt/opt, create a symlink at /usr/lib/gcc linking to /mnt/opt/gcc
<Gramdalf> that could work
Ansuel has quit [Ping timeout: 480 seconds]
Borromini has quit [Quit: leaving]
Ansuel has joined #openwrt-devel
dgcampea has quit [Remote host closed the connection]
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<stintel> Ansuel: just git send-email it
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
<Tapper> f00b4r0 did you get your ram working? If not try updateing bios or bumping Dram voltage by .1
<jow> hmm, is make ... IGNORE_ERRORS=m still supposed to work=
<jow> ?
bluew has joined #openwrt-devel
<Ansuel> (jow can you help me by chance with the new repository problem?)
<jow> having a CONFIG_xxx=m package here that fails to build against current openssl, yet the build keeps failing despite make IGNORE_ERRORS="n m"
robimarko has quit [Quit: Leaving]
soxrok2212 has quit [Remote host closed the connection]
<jow> Ansuel: what kind of repo problem?
soxrok2212 has joined #openwrt-devel
<Ansuel> jow we want to move some board file from the openwrt main repo to a separate repository... wanted to create a repo on our git server but i don't have permission... The name was /firmware/qca-wireless
<Ansuel> or you prefer creating it directly on github ?
<Ansuel> yes
<Ansuel> no wait project/firmware/qca-wireless
<jow> can you give me a one-limne description?
<Ansuel> Qcom Wireless Device BDF (Board Data File)
<jow> done
<Ansuel> thanks!
<jow> yw
<Ansuel> jow guess i also have to create the mirror to github
Tapper has quit [Quit: Tapper]
<jow> I don't know how the mirroring is set up atm
<Ansuel> np thanks anyway!
<jow> hm, mirroring is set up for any project/* repo
<Ansuel> it may be already setup
<jow> but you likely need to create the remote repository counterpart
<jow> thne push something and it should get pushed the mirrored contents
<Ansuel> yep i pushed before creating the github repo so my bad i guess
<Ansuel> just my concern is how / is translated to the giithub mirror since we are converting / to _
<jow> likey not at all
<jow> ah actually we do :)
<jow> git push --mirror "git@github.com:openwrt/${PROJECT_NAME//\//_}.git"
<Ansuel> very nice! ok then will be autofixed on the next push
danitool has joined #openwrt-devel
Ansuel_ has joined #openwrt-devel
Ansuel__ has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
Ansuel__ has quit [Read error: Connection reset by peer]
mcbridematt has joined #openwrt-devel
Ansuel_ has quit [Ping timeout: 480 seconds]
<Ansuel> stintel this is the patch
<Ansuel> but again not sure this is the correct solution but just another workaround to a more latent problem with interface not IFF_RUNNING
<Ansuel> it's just a cleaner implementation that yours
<jow> hauke: regarding the autotools/SDK failures
<jow> hauke: I think the relocatable patch needs to be amended
<jow> there's likely new places introducing hardcoded paths which need to get patched to use the $STAGING_DIR env var
<Ansuel> jow context of the problem ?
<jow> Ansuel: someone felt the urge to touch autotools and messed it up
<jow> new, updated autotools executables contain harcoded references to the absolute path of the original buildroot path
<jow> this breakes SDK relocatability
<Ansuel> asking since it's strange to only notice now, afaik the changes are old
<jow> merged two days ago
<Ansuel> ok the autothing bumps
<jow> checking my recent build: staging_dir/host/bin/autoconf contains
<jow> : ${trailer_m4='/home/jow/devel/lede/staging.git/staging_dir/host/share/autoconf/autoconf/trailer.m4'}
<jow> not moved into the existing if test -n "$STAGING_DIR_HOST"; then
<jow> ... block
<Ansuel> not following why so much change in the relocatables patches
<Ansuel> --my @automake_includes = ("@datadir@/aclocal-$APIVERSION");
<Ansuel> +-my @automake_includes = ('@datadir@/aclocal-' . $APIVERSION);
<Ansuel> strange?
<jow> upstream change
<jow> likely to prevent code injection through @datadir@
<Ansuel> anyway the thing you notice is correct... but who knows if there are other problem... think a general check of the source is needed
<jow> a general purge of anything autotools is needed
<Ansuel> ahahahah the dream
<jow> a common CI check wouldn't have catched this either, most likely
<jow> it only affects the SDK and only if unpacked into a directory not matching the original buildroot directory
<Ansuel> eh wanted to fix odhcpd but can't resist checking this autotool thing
<jow> just pushed a fix
<jow> it was just a new variable pointing to a hardcoded path that had to be moved under the existing if/else guards
<jow> so basically an incomplete patch rebase
<Ansuel> lovel path structure /share/autoconf/autoconf/trailer.m4
<hauke> jow: thanks for fixing
<hauke> I think this fixes gnutls build: https://github.com/openwrt/openwrt/pull/12185/files
<jow> yo dawg, I heard you like directory hierarchies, so I've put a subdir in your subdir so that you can recurse while you recurse
<jow> hauke: yes, most likely - unless the surrounding make code expects this command to actually produce some result file
<jow> which is used by subsequent make rules/targets
<jow> hauke: yw
<hauke> yw?
<Ansuel> you are welcome ?
<Mangix> how: ping
<Mangix> *jow
<hurricos> lol 5.15 breaks ethernet on hiveap 330
<Ansuel> stintel ping ?
<hurricos> at least it doesn't break boot :^)
<Ansuel> just discovered ipv6 link-local address is assigned only with interface set to IFF_RUNNING