dangole has quit [Ping timeout: 480 seconds]
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
SlimeyX_ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
floof58 is now known as Guest410
floof58 has joined #openwrt-devel
Guest410 has quit [Ping timeout: 480 seconds]
valku has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
danitool has quit [Ping timeout: 480 seconds]
Acinonyx has quit [Quit: Peer reset by connector]
Acinonyx has joined #openwrt-devel
<Znevna> aiyion: I don't know, don't think so
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
Tapper has joined #openwrt-devel
<dwfreed> stintel: did you ever figure out if there are actually 2 CPU ports attached to the switch chip in the m300?
rafelbev has quit [Remote host closed the connection]
gch981213 has quit [Ping timeout: 480 seconds]
<stintel> dwfreed: the oem bootlog and gpl drop seem to suggest this is the case but I never managed to have any traffic with any other port besides the one is currently configured as CPU port in the DTS
<Znevna> if we add an alternate name for a device using DEVICE_ALT0_MODEL, can we ommit the vendor if it's the same as DEVICE_VENDOR ?
<stintel> interesting ... wg_dsa_count is 1 for the T2081
<stintel> ah nvm that just means there is a single switch chip
<dwfreed> I mean, does the marvell dsa driver support multi port?
<stintel> + // Set which ports are CPU ports based on platform
<stintel> + CPU0 = DSA_PHY;
<stintel> + CPU1 = (wg_dsa_count == 2) ? DSA_PHY : (DSA_PHY + 1);
<stintel> +// Define which ports are CPU ports
<stintel> +static int CPU0;
<stintel> +static int CPU1;
<stintel> dwfreed: afaik dsa does not support this at all in 5.15 so it requires backporting
<stintel> iirc Ansuel mentioned the kernel folks decided to go for LACP
<stintel> these code snippets seem to suggest port 5 and 6 on the switch are connected to the soc
<stintel> but I never got port 5 to work (disabling port 6 as there is no multi-cpu-port support at all)
<dwfreed> I'm assuming that diff is from the gpl dump?
<stintel> yeah
<stintel> GPL dump
<stintel> I like the bonding/teaming idea, but not sure if anyone actually worked on it
<Znevna> x.x
<stintel> lol
<Znevna> I just can't
<stintel> yeah I'm not taking the bait :P
<dwfreed> should just disable DMs on the forum
<stintel> we actually use the forum DMs to communicate with some team members
<stintel> that aren't on IRC
<dwfreed> restricted to team members, then?
<stintel> anyway
<stintel> last day of my 2w holiday
<stintel> afk
cbeznea has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
hhasert has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
hhasert has quit []
Borromini has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
csharper2005 has quit []
csharper2005 has joined #openwrt-devel
TTuner has joined #openwrt-devel
<TTuner> hello, is there anyone around who has tried or runs openwrt on top of rpi zero 2 w?
<robimarko> If you dont have WLAN working
<robimarko> Thats expected AFAIK as no FW is includede
TTuner has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
floof58 is now known as Guest436
floof58 has joined #openwrt-devel
Guest436 has quit [Ping timeout: 480 seconds]
sorinello has quit [Quit: Leaving]
sorinello has joined #openwrt-devel
xes_ has quit [Read error: Connection reset by peer]
xes has joined #openwrt-devel
<aiyion> The device I'm currently testing behaved interesting, as I tested it last (a few days before christmas). Wireless interfaces were not showing up in `ip a` but only after I fired them up. And then they wouldn't be called wlan1, but just pyh0-sta0 fo example.
<aiyion> I'm just building the patch again rebased on tonights master to see if the issue is gone. Any thoughts when such such behaviour may occur?
<Borromini> aiyion: phy0-sta0 is the new naming introduced in master recently afaik
<Borromini> i thought it was a netifd change but I'm not finding it
<Borromini> can't comment on the behaviour you're seeing
<aiyion> mhm. I booted the new image from tonight.
<aiyion> The interfaces wlan0 and wlan1 are listed.
<aiyion> I enable the default openwrt ssid in luci and they disappear from `ip a` and phy0-ap0 and phy1-ap0 spawn.
<aiyion> Is that really intended behaviour?
<aiyion> I disable them again and wlan0 and 1 do not show up again.
<aiyion> ... funny. That is until I reboot after disabling again. Then they're back.
<aiyion> Same thing without luci involved: https://bpa.st/JYDAE
chsarper2005 has joined #openwrt-devel
<Borromini> stintel: you're using Home Assistant right? Or still Domoticz?
minimal has joined #openwrt-devel
<chsarper2005> Hi guys! Whats's the simplest way to increase the first octet of MAC? e.g. 68:xx:xx:xx:xx:xx -> 72:xx:xx:xx:xx:xx (increase by 0xa)
<Borromini> chsarper2005: just set it manually?
hexagonwin has joined #openwrt-devel
<chsarper2005> Borromini: I would like to write such command in 02_network script for the new device.
danitool has joined #openwrt-devel
Backhand4630 has quit [Quit: Textual IRC Client: www.textualapp.com]
<Ryncewynd> maybe something like that ?
<chsarper2005> Ryncewynd: maybe. thanks for the idea. it looks like there is no existing function in OpenWrt (like macaddr_add) for my case and I need to write a new one.
<rmilecki> csharper2005: huh? we have function for that
<rmilecki> csharper2005: ah, it's macaddr_add() actually
<rmilecki> csharper2005: ah, wait, macaddr_add() allows increasing last 6 bytes, not first 6 bytes
<rmilecki> csharper2005: you don't want to increast first 6 bytes as that is vendor part
<rmilecki> OUI
<chsarper2005> rmilecki: here are the MACs:
<chsarper2005> LAN 68:FF:xx:xx:37:F4
<chsarper2005> WAN 72:FF:xx:xx:37:F5
<chsarper2005> 5g 68:FF:xx:xx:37:F6
<chsarper2005> 2g 68:FF:xx:xx:37:F4
<rmilecki> chsarper2005: that isn't increasing
<rmilecki> that is setting local bit
<chsarper2005> rmilecki: 3 bytes changed. That's strange...
<chsarper2005> 68 = 0110 1000
<chsarper2005> 72 = 0111 0010
<rmilecki> ok, that is weird
decke[m] has quit [Quit: Client limit exceeded: 20000]
<rmilecki> normally you're allowed to set 0x2 in the left most octet as that means locally-assigned Ethernet address
<rmilecki> 0x68 -> 0x72 i can't explain
<karlp> depending on the board, that's not wildly unreasonable.
<karlp> intel mac on wan, realtek on lan for instance...
<karlp> or mediatek on lan/2g/5g, realtek usb ether on wan, could be anything.
<rmilecki> that WAN has local bit set so it seems like some vendor messing with that
<rmilecki> maybe they implemented some incorrect logic
<rmilecki> like +=0xa instead of |=0x2
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<karlp> chsarper2005: do you really have lan and 2g with the same mac?
<chsarper2005> karlp: Yes, I'm sure.
<karlp> cute.
<karlp> soundsd like a vendor script fuckup :)
<chsarper2005> rmilecki: What would you suggest? 1. Fix possible mistake? 2. Keep original WAN MAC logic? 2а. Using set/unset bit. 2b. Add 0xa with new function.
Ansuel has joined #openwrt-devel
<Ansuel> jow ping?
domon has quit []
<chsarper2005> karlp: this is not the first such device in my practice :) with 2g MAC = LAN MAC
<Znevna> OpenWrt guidelines suggest keeping the MACs how they were set in the vendor firmware
lipnitsk has quit [Quit: Client limit exceeded: 20000]
<chsarper2005> Znevna: set/unset bits will be the easiest way...
<Ryncewynd> the guideline should say "unless the vendor fucks up" :-)
<Ryncewynd> 2.a is the cleanest approach
MatMaul[m] has quit [Quit: Client limit exceeded: 20000]
<Ryncewynd> I mean its 1 by implementing the set/unset bit
<rmilecki> csharper2005: i don't know... my personal choice would to to look for other owners of that device model
<rmilecki> see how MACs are handled in other units
<rmilecki> maybe find some pattern that way
<Ryncewynd> true, the 72 might be a mistake and actually they should all be 68, my device does not apply local/global logic
<Ryncewynd> I have a different model though (tp-link archer c7 v2)
borek has joined #openwrt-devel
<chsarper2005> Thanks, guys. I'm working under this device - https://wikidevi.wi-cat.ru/TP-LINK_EC330-G5u_v1.x
Borromini has quit [Ping timeout: 480 seconds]
cbeznea has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
<stintel> hmmm, anyone noticed any performance regressions in cake recently? steam was stuck at ~38MB/s, stop qosigy and now it's doing 106MB/s
<Ansuel> this is on wifi or ethernet ?
<stintel> ethernet
<stintel> friends don't let friends game over wifi :P
<stintel> perf top doesn't point to anything obvious
<stintel> lots of .book3e_idle
<chsarper2005> Ryncewynd: Now I have the another example. LAN: 50:xx:xx:xx:B7:DA, WAN: 54:xx:xx:xx:B7:DB. The only idea I have that TP-Link fw is handling 50->54, 68->72 as decimal numbers. +4. lol
<stintel> guess I'll be bisecting again
<stintel> sigh
valku has joined #openwrt-devel
SlimeyX_ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
<Ryncewynd> chsarper2005: LoL, it comes from the Mediatec chips, they count in chinese ;-)
<Ryncewynd> second bit, that is +4 right, so 50 + 4 ... ah, hmm
<Ryncewynd> So seems like the extention to the rule: " unless the manufacturer fucks up and adds 4" ;-)
srslypascal is now known as Guest460
srslypascal has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
Guest460 has quit [Ping timeout: 480 seconds]
<Ryncewynd> chsarper2005: If you find two of these great implementations of the incorrect logic I would go for option 1, fix it
<Ryncewynd> chsarper2005: I mean +4 might even belong to a different vendor.
Borromini has joined #openwrt-devel
<chsarper2005> Ryncewynd: I agree with you. I'll describe this situation in PR.
<chsarper2005> thanks!
<chsarper2005> I prefer not to touch OUI at all. Keep original TP-Link 68:xx and 50:xx. What do you think?
<Ryncewynd> chsarper2005: I would agree, no tinkering with local/global bits
<Ryncewynd> chsarper2005: you can see in the last hex number that they intended to have it +1 sequence anyway
<Ryncewynd> chsarper2005: so no conflict if you keet 68 or 50
<Ryncewynd> *keep
<Znevna> nbd: hello, can we merge this? https://github.com/openwrt/mt76/pull/725
borek has quit [Ping timeout: 480 seconds]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
<nbd> Znevna: done
<Znevna> thank you, sorry for the noise :s
<Znevna> we didn't find a better option yet, and since the same is done for mt7615 I went with that
<aiyion> nbd, Znevna: Waht would be needed for a backport of the LED changes to openwrt-22.03?
<aiyion> for the RT-AX53U that would be #11601 and in some form the mt76 PR?
minimal has quit [Quit: Leaving]
goliath has joined #openwrt-devel
Backhand4630 has joined #openwrt-devel
Ryncewynd has quit [Quit: Leaving]
<Backhand4630> hey, since the transition from ar71xx to ath97 there is no more system.usb_power_switch available in uci.
<Backhand4630> one could switch the power state with "echo '1' > /sys/class/gpio/gpio52/value"
<Backhand4630> back in the LEDE days when the power_switch was not implemented
<Backhand4630> how can i do this with the new kernel? :S
<Backhand4630> i tried compiling with it, and it becomes available in uci, however does nothing
niyawe has quit []
Borromin1 has joined #openwrt-devel
niyawe has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
<robimarko> You sure that the GPIO base is correct?
<robimarko> I would bet its 400+
<Backhand4630> nah that was the old kernel system
bluew has joined #openwrt-devel
<Backhand4630> just found out
<Backhand4630> echo 1 > /sys/class/gpio/power-pcie/value
<Backhand4630> echo 0 > /sys/class/gpio/power-usb/value
<Backhand4630> i have to do that on every start. where is the correct place to put it?
<Borromin1> /etc/rc.local
<Backhand4630> really? i had hoped to do it very early in boot, so my modem is ready when interfaces are initializing etc.... i wanted to put it in /etc/board.d
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<Borromin1> that sounds even more hacky to me since those files will be overwritten upon upgrade
<Borromin1> if you want to make it persistent, wouldn't the DTS be a more logical place? Which means recompiling of course.
csharper2005 has quit [Remote host closed the connection]
<Backhand4630> you are right.
chsarper2005 has quit [Ping timeout: 480 seconds]
chsarper2005 has joined #openwrt-devel
chsarper2005 is now known as csharper2005
Borromin1 has quit [Quit: leaving]
Backhand4630 has quit [Quit: Textual IRC Client: www.textualapp.com]
<stintel> hmmm so looks like it might be a 6in4 tunnel over an ethernet interface with cake where there is a major performance problem
<stintel> could have been always there, and just now showing up as more parties enable IPv6 on their end
<stintel> yep, speedtest.net uses IPv4 servers, not an issue there
<stintel> blergh
csharper2005_ has joined #openwrt-devel
csharper2005_ has quit []
<f00b4r0> stintel: wrong overhead estimate?
<stintel> f00b4r0: I didn't specify overhead, but dropping from ~900Mbps to ~300Mbps ...
<f00b4r0> ouch indeed
<f00b4r0> try setting Ethernet link layer and 44 overhead. Sebastian Moeller seemed to suggest it can have a significant impact.
cbeznea has quit [Quit: Leaving.]
<stintel> f00b4r0: hmmmz
<stintel> f00b4r0: ethernet == overhead 38 mpu 84 noatm
<stintel> so your suggestion is confusing ;)
<f00b4r0> as he explained, overshooting is better than underestimating
<f00b4r0> i don't know what kind of tunnel overhead you're facing
<stintel> so overhead 44 mpu 84 noatm
<f00b4r0> i guess so
<f00b4r0> i find cake "no knob" to be not so "no knob" after all. And quite confusing, to the point that I've not been through with my plan to improve the documentation
<f00b4r0> and i also noticed recently that fq_codel _actually no knob_ config performed outrageously well for my needs on the underpowered hap-ac2 that I use here :)
<Znevna> aiyion: I don't know how backporting usualy works
<aiyion> How it usually works I do know; I'm just not sure about how or even whether mt76 patches can land in 22.03 domain.
<f00b4r0> then can, if there is a compelling reason
<f00b4r0> (compelling reason = fixing a bug, not adding a feature)
<stintel> hmmz
<Znevna> aiyion: the power led and usb led deserve to be fixed in 22.03 too anyway
<Znevna> those don't depend on anything from master
<aiyion> Not sure whether that goes for the radio LEDs as well.
<f00b4r0> I'm afraid I'm going to go postal
<aiyion> good one ^^
<slh> big thumbs up from me :)
<f00b4r0> i tried to stay civil
<stintel> I'm going to close that tab
<f00b4r0> but these "we need you to fix this" demands do get me boiling.
<f00b4r0> stintel: heh :)
<stintel> if I made any new years resolution it's to avoid getting involved in pointless discussions like this
<f00b4r0> ha; that's a wise one
<stintel> it drains energy and demotivates
<f00b4r0> I should follow
<owrt-snap-builds> Build [#750](https://buildbot.openwrt.org/master/images/#builders/50/builds/750) of `mediatek/mt7623` failed.
<f00b4r0> I'm also not quite clear what kind of upstream contribution freifunk provides, so I didn't want to go down that road. But did I hate the tone of that message.
<slh> it's particularly ridiculous, as freifunk is a disjunct group of regional projects with their different code bases - and for many of those, IPv6 is a necessary core feature for their own routing
<stintel> Adrian did a lot of contrib
<stintel> with a freifunk@ alias
<f00b4r0> slh: interesting. That makes this even more retarded than I first thought then ;P
<aiyion> We're not all like that, promised.
<slh> f00b4r0: the problem for many of these is that they're sitting on mountains of 4/32 tl-wr841n routers deployed in the field - as it was easy to recommend them as under-20-EUR solutions
<Habbie> hah, i have five of those
<Habbie> one runs openwrt
<Habbie> 18.xx or something
<Habbie> (terrible)
<f00b4r0> slh: heh. well I think these are way past their due date. And certainly largely economically amortised by now.
<dwfreed> 18.06 is the 18 version, yeah
<stintel> lol 4/32 people are really still running that now ?
<f00b4r0> i have a couple of these types of devices, it would never cross my mind to /demand/ they be supported forever. That's beyond absurd.
<stintel> I can barely fit my minimal requirements in 8MB
<f00b4r0> stintel: I am :D
<Habbie> stintel, i am!
<Habbie> but i missed the conversation
<f00b4r0> as dumb AP
<stintel> actually I can barely fit my dumbAP in 16MB
<Habbie> i would definitely not demand support
<Habbie> f00b4r0, dumb client here
<f00b4r0> stintel: then you dumbAP is not so dumb ;)
<slh> f00b4r0: still very hard to replace, as they're owned/ paid by their individual operators, with very little means of contact or other ways to plan forward
<f00b4r0> slh: I'm afraid that's *their* problem
<stintel> f00b4r0: snmp and lldp is non-negotiable :)
<f00b4r0> stintel: lol
<slh> it is, I'm just mentioning it to explain the thinking behind it
<f00b4r0> *nod*
Slimey_ has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<dwfreed> probably a load of microscopic gl.inet devices that would be better than that
<f00b4r0> i should take a closer look at gl.inet, seems people like it.
<f00b4r0> client of mine is asking what should be their next hw investment for openwrt use ;)
<Habbie> gl.inet comes up a lot in conversations i have with people on wide ranging subjects
<Habbie> both "travel routers" and "we develop on these"
<Habbie> (these two don't overlap much)
<slh> f00b4r0: the interesting/ recent gl.inet devices are typically not supported by OpenWrt anymore (new SOCs)
<f00b4r0> ah damn
<Habbie> the second group does mention "best i can do is 19.07" on lucky days
<slh> still plenty of older designs (ath79/ mt7621) which are fully supported, but at least I wouldn't be interested in buying those anymore
<slh> ipq60xx wouldn't be that far away from prime time, the others will have worse chances
<dwfreed> slh: the original beryl is supported from 21.02 (but you need 22.03 for the wifi to work correctly)
<dwfreed> that's mt1300
<dwfreed> it's not AX, but do you really need AX for a travel router?
<slh> dwfreed: well, beryl is a 'boring' mt7621a ;)
<f00b4r0> but mt7621 is rock solid, and that's cool :)
<slh> support for opal (SF19A28) looks grim (as in probably not going to happen), brume2 (MT7981B/ filogic 820) looks promising (underway, but apparently not ready, yet), slate should be supported as well (ipq4018)
<dwfreed> I also have an old mt300n, pretty sure it's v1
<stintel> yep, have a beryl here too, good stuff
<stintel> and convexa-b
<aiyion> I'm still looking forward to eventually get that brume2 running.
<stintel> yes, that brume2 looks fun toy
<jow> hmm, anyone know what's the deal with adding more and more hardcoded fdt-to-pci-id mappings to libiwinfo?
<dwfreed> stintel: brume2 has a really weird port setup
<dwfreed> 1x 2500, 1x 1000, no wifi
<f00b4r0> now that's rather weird indeed
<dwfreed> and the 2500 port is labeled "WAN"
<f00b4r0> i'm guessing that's all about ticking that "2.5GE" marketing checkbox
<slh> jow: with everything relevant being mac80211 these days, there might be a point to drop any kind of detection in libiwinfo (respectively to outsource it to pciids/ usbids, if installed), both ipq8074 and qcnx0x4 are very common targets though (qcn9074 as third radio (6 GHz or second 5 GHz radio as wireless backhaul)
<aiyion> two 2.5 ports would've been nice, but having that device as a router on a stick with still a gigabit of bandwidth is quite nice.
<slh> jow: 7 devices using those are already part of the (upcoming) ipq807x target PR, another 2-3 are in-waiting, while relatively minor kinks are resolved - and quite a few more with as-of-yet-unported devices and ipq60xx to follow
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (14.2% images and 99.4% packages reproducible in our current test framework.)
<stintel> if it would be PoE-PD I would have ordered 2 without hesitating
<slh> https://wikidevi.wi-cat.ru/index.php/Special:Ask?title=Special%3AAsk&q=%3Cq%3E[[CPU1+model::~IPQ807*]]+OR+[[CPU2+model::~IPQ807*]] the currently known potential candidates for ipq807x and https://wikidevi.wi-cat.ru/index.php/Special:Ask?title=Special%3AAsk&q=%3Cq%3E[[CPU1+model::~IPQ60*]]+OR+[[CPU2+model::~IPQ60*]] for ipq60xx
<stintel> and you can always use the "WAN" interface with VLANs so you have 2.5GbE WAN+LAN but somewhat half-duplex
<f00b4r0> stintel: i was thinking exactly that, but that's not very pretty
<stintel> yeah, weird designs ... :)
MAbeeTT2 has quit [Read error: Connection reset by peer]
<f00b4r0> :)
<stintel> anyone have a couple million EUR too many?
<dwfreed> and only 25% faster than not
<f00b4r0> stintel: sure, in my back pocket. What for? ;)
MAbeeTT2 has joined #openwrt-devel
<stintel> to build less weirdly spec'd hardware. with a few non-negotiable base features
<stintel> RJ45 console port
<f00b4r0> ;)
<aiyion> :D
<stintel> non-crippled u-boot
<stintel> (or other bootloader)
<f00b4r0> 4x 10G ethernet and 2 SFP+ cages (let's be rad)
<stintel> well I'd like a 2x 10GbE PoE++-PD device with HA PoE-PD over those
<f00b4r0> sounds good. I can live with that xD
<stintel> but not sure if there's going to be a lot of demand for something like that :)
<f00b4r0> hehe
<aiyion> gn
<jow> slh: the libiwinfo fdt stuff seems to map fdt compatible values to (fake?) PCI IDs
<f00b4r0> yeah same. nn
<jow> slh: so you'd still need some database holding the /sys/class/ieee8021/phy*/device/of_node/compatible => PCI ID mapping
<jow> or any other mechanism
<slh> yeah, probably (I haven't any ipq807x with accessible OEM firmware around to check that, only an ax3600 which is already running Robert's code)
Ansuel has joined #openwrt-devel
<jow> Ansuel: pong
<f00b4r0> jow: missing negation in your email I think
minimal has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
<owrt-snap-builds> Build [#760](https://buildbot.openwrt.org/master/images/#builders/22/builds/760) of `ipq40xx/generic` failed.
<owrt-snap-builds> Build [#262](https://buildbot.openwrt.org/master/images/#builders/79/builds/262) of `ipq40xx/chromium` failed.
<robimarko> jow: I am aware that that compatible matching/fake PCI ID isnt great
<robimarko> But I dont really have an idea how to improve it
<robimarko> And no time to work on that at this point
<robimarko> ipq807x target is pretty much ready, I plan to make a PR in a day or two
<Slimey> heh
robimarko has quit [Quit: Leaving]
zer0def has quit [Ping timeout: 480 seconds]
zer0def has joined #openwrt-devel