xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
hanetzer has joined #openwrt-devel
shoragan has quit [Quit: quit]
<slh>
dhewg: ipq60xx (for ipq601x and higher) support would be quite reasonable, now that ipq807x is merged, but it will need some work - ipq50xx is better best avoided (but you will undoubtly see lots of hardware with it, fishing at the bottom of the barrel)
srslypascal has joined #openwrt-devel
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
minimal has quit [Quit: Leaving]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
lmore377 has quit [Read error: Connection reset by peer]
lmore377_ has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
tomn has quit [Remote host closed the connection]
tomn has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
gch981213 has quit [Ping timeout: 480 seconds]
guidosarducci_ has quit [Remote host closed the connection]
valku has quit [Read error: Connection reset by peer]
<dhewg>
slh: I prefer having one device with DSL support, and that limits to choices to just a handfull. While ipq4019+vrx518 isn't last-gen, it's a big step up from lantiq+vr9
goliath has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
shoragan has joined #openwrt-devel
philipp64 has quit [Read error: Connection reset by peer]
philipp64 has joined #openwrt-devel
srslypascal has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
robimarko has joined #openwrt-devel
srslypascal is now known as Guest2264
srslypascal has joined #openwrt-devel
Guest2264 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
Ryncewynd has joined #openwrt-devel
<robimarko>
Anybody willing to merge the ath25 source-only patch?
<robimarko>
By the looks of the 5.15 PR for it, it doesnt even look able to boot due to only 32MB of RAM
goliath has joined #openwrt-devel
<ynezz>
robimarko: IIRC dangole was saying something, that he might be somehow forced to make 5.15 working on that target, so maybe you should ping him?
<robimarko>
Well, as far as I remember we did discuss it here with him some time ago
<robimarko>
No idea how you can force it to work on 32MB?
<ynezz>
if it wont be capable for running 23.x, then I would remove that target, IMO there is no reason to keep it source only
svanheule has quit [Quit: svanheule]
<robimarko>
Well, I sent that before it was known it cannot actually boot 5.15 currently
<robimarko>
As there are only downstream image users of that target
<dhewg>
from the mailing list: "If it's triggered, it's bad: dnsmasq logs about cache internal error and the DNS subsystem becomes broken"
<dhewg>
funky typo too, "stumpled", a mix of stumped and stumble I guess, for once it even fits
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
<mrkiko>
PR #11867 (lzma loader unification) can become very interesting - and solve one of those outstanding issues that take long time to get resolved. Any help and attention very much apreciated.
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
zer0def has quit [Ping timeout: 480 seconds]
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
zer0def has joined #openwrt-devel
floof58 is now known as Guest2277
floof58 has joined #openwrt-devel
Guest2277 has quit [Ping timeout: 480 seconds]
bluew has quit [Quit: Leaving]
xback has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
<karlp>
anyknow know if you you can set scp -O via .ssh/config? I can't find it, only methods to ban scp protocol entirely?
<dhewg>
Ansuel: is it possible that asu replaces newer package version from with the image with older ones if the snapshot packages haven't been updated yet?
<dhewg>
*within
<dhewg>
I just don't get it how the user ended with that mix
<dhewg>
it's image-builder, does asu use that under the hood?
<robimarko>
ASU just uses image builder to generate the images
<robimarko>
So, I guess if you have a local build that is newer than the snapshot IB you can end up with older packages
<dhewg>
it's probably just a small time window where this happens, but that really shouldn't happen
goliath has quit [Quit: SIGSEGV]
<robimarko>
Well, I assume that ASU fetches IB tarballs every so often
<f00b4r0>
imho IB is not very suited for master
<f00b4r0>
this is always going to happen, ensuring that it does not would require quite a bit of work I believe.
<robimarko>
ASU would need to become and integral part
<robimarko>
*an integral part
<robimarko>
And basically get a notification once builds are complete to immediatelly update its imagebuilder
<f00b4r0>
the problem would still be there
<robimarko>
Ah yeah, you are still downloading the packages
<f00b4r0>
you will always have a window of time where you can fetch an IB that is outdated vs ToT
<f00b4r0>
exactly.
<f00b4r0>
so, live with it imo :)
<dhewg>
images and packages could just be published atomic
<f00b4r0>
no they can't
<f00b4r0>
unless aforementioned serious rework
<robimarko>
They are completely separate build phases
<f00b4r0>
packages cover architectures which span several targets. Images are per target.
<dhewg>
they are, and whatever is build first and who needs what, why can't they be http exposed at the same time?
<f00b4r0>
because you can't expose the packages until all targets are up to date *AND* in sync. And they may never be, due to the rolling nature of master and occasional build failures.
<f00b4r0>
trust me, getting what you ask for to work would be a tall order.
<f00b4r0>
s/all targets/all targets that relate to a given package architecture/
<dhewg>
I can imagine that, and I may be missing internal details, but the Makefiles are full of 'cp $a $a.tmp && dostuff $a.tmp && cp $a.tmp $a", which in my ignorant mind is the same problem on a tiny scale
<f00b4r0>
i think snapshot ASU should be considered a PoC; not something production ready.
<robimarko>
Its working as good as its gonna be
<f00b4r0>
no it has nothing to do with that.
<f00b4r0>
^
<robimarko>
With current HW, if we waited for everything to be in sync we would be like week or two behind current commit
<robimarko>
As buildbots are lagging 2-3 days currently
<f00b4r0>
and it may never happen.
<robimarko>
Yeah
<robimarko>
Not to mention that it would require a complete rework of the current setup
<f00b4r0>
that too.
<dhewg>
hm
<dhewg>
luci currently drags in asu per default, maybe that was too early if it's considered a poc?
<blogic>
no rush, need to pick up kid and then feed her
<blogic>
grrrr
<blogic>
-EWIN
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
xback has joined #openwrt-devel
goliath has joined #openwrt-devel
<f00b4r0>
xback: i think you're still missing the issue, which is sysupgrade rebooting before the image is fully written. IIRC stintel had dug though this on a watchdog problem and I wonder if this may be related
mcbridematt has quit [Ping timeout: 480 seconds]
* f00b4r0
notices his email reply didn't leave outbox
mcbridematt has joined #openwrt-devel
Lynx-- has joined #openwrt-devel
Lynx- is now known as Guest2299
Lynx-- is now known as Lynx-
Guest2299 has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Ping timeout: 480 seconds]
<dhewg>
Ansuel: that's based on a mail from october heh
mcbridematt has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
<Ansuel>
dhewg thing is that the conv stalled and greg didn't replay
Lynx- has quit [Ping timeout: 480 seconds]
<Ansuel>
robimarko the ax3600 topic is getting so fun
<robimarko>
Ansuel, its getting crazy
<robimarko>
So, I am just glancing over and not replying to that mess
<Ansuel>
curious if i should put my 700mbps speedtest to that random guy that say perf are shit
<robimarko>
I stopped caring about those long time ago
<robimarko>
They are free to contribute, stock FW is always there with offloading
<Ansuel>
yep but i remember at times ipq806x community was much better full of devs that wanted to contribute
<Ansuel>
we are for real living in different times
<Ansuel>
sad
robimarko_ has joined #openwrt-devel
<robimarko_>
Well, there are people here and there that contribute something back
<robimarko_>
Even if just by testing or reproducing bugs
<robimarko_>
But others are just "I get XYZ on stock FW" or "I bricked it by not reading instructions"
noltari has quit [Quit: Bye ~ Happy Hacking!]
Lynx- has joined #openwrt-devel
<robimarko_>
Those loud ones just drown everybody that is trying to improve something
<Ansuel>
yep
Lynx- has quit [Remote host closed the connection]
<robimarko_>
BTW, I have been poking around and I think that EIP197 engine will be compatible with the upstream driver
<robimarko_>
It looks like register offsets are different and there is one more clock
<Ansuel>
expected but the upstream one works on a reduced version
<Ansuel>
donated by marvell to be free
<robimarko_>
Oh you mean FW
<robimarko_>
It runs on the full FW if you have it, its just not redistributable
<Ansuel>
oh ok so the upstream one is also compatible with the full variant
<robimarko_>
Yes
noltari has joined #openwrt-devel
<robimarko_>
It will just fallback to the mini FW as that one can be freely distributed
<robimarko_>
Driver isnt using any of the advanced features of the full FW anyway
<Ansuel>
ok so my theory is that with the right clock and reg
<Ansuel>
it will 99% work
<robimarko_>
Oh yeah
<robimarko_>
That is my current project, that would allow using it properly without fixing those NSS crypto conversions
<Ansuel>
also the driver attach to cryptodev right ?
<robimarko_>
Its in kernel so it will register the algos with kernel and then you can use cryptodev yes
<robimarko_>
Sounds like a better idea than sinking more time into NSS
<Ansuel>
well the nss-drv is already crazy... crypto is pure hell
<Ansuel>
like an entire level of hell
<Ansuel>
ahahah
<robimarko_>
Yeah
<robimarko_>
I would love to get bridge, VLAN and PPPoE offloading with NSS
<robimarko_>
That would solve like 99% of perf issues
<Ansuel>
we can consider adding the nss-drv if we really want but for vlan and pppoe offload it does require kernel patching
<robimarko_>
If you use their client modules
<robimarko_>
But, if we manage to use flowtables
<robimarko_>
Then not
* f00b4r0
tears open a cheap 1-to-2 PoE gigabit splitter and finds an RTL8367N sitting inside + what appears to be a config eprom, ponders hacking this to make it a bit smarter ;)
<Ansuel>
robimarko_ no idea if we should invest time in that or creating a better nss-drv
<Habbie>
f00b4r0, ohh, i found 8367 + config eeprom in a dumb switch recently, same plan
<f00b4r0>
Habbie: 👍
<Habbie>
f00b4r0, if you want to talk to the rtl i2c, note that you can likely to that via pins on the eeprom, which are nicely 2.54mm spaced
<Habbie>
(on mine anyway)
<robimarko_>
Ansuel: It would be more than ideal to write a better one
<f00b4r0>
yeah this looks narrower (TSSOP package) but still manageable
<robimarko_>
Probably as part of the network driver
<Habbie>
f00b4r0, right, still beats the rtl pins i think?
<f00b4r0>
also nice that the datasheet is available
<russell-->
i'm trying to hunt down when 3des-cbc support was dropped from openwrt's dropbear (this is just to be able to transfer data off of an ancient device that needs it)
<russell-->
Author: Felix Fietkau <nbd@openwrt.org>
<hauke>
russell--: I think you can tell openssh to use legacy protocols too
<hauke>
at least I can add an execption to access openwrt 19.07 with a recent openssh
<hauke>
maybe your stuff is too old and they removed the code
<mrkiko>
someone can decode for me what this line does ? dd if=/tmp/ApplicationData/boot/bootconfig_new.bin 2>/dev/null | mtd -e "/dev/mtd2" write - "/dev/mtd2" 2>/dev/null especially the "mtd tool" usage - is it telling "erase and then write"?
* russell--
considers starting an extra sshd on a non-22 port with enabling options
<russell-->
i can't log in to the ancient device because i don't have working credentials
Borromini has joined #openwrt-devel
<Ansuel>
mrkiko just read using dd tool | mtd write from stdin
<Habbie>
what's "mtd"? i can find mtdinfo, mtdpart etc.
<Borromini>
that's a separate package afaik, mtd-utils
<Habbie>
ok package/system/mtd/Makefile
<Ansuel>
should be pretty standard
<Borromini>
sorry yes 'mtd'
<Habbie>
on openwrt, yes
<Borromini>
most NOR devices have it onboard with OpenWrt
<Ansuel>
some OEM fw use the meme nvmem
<Habbie>
ack
<Ansuel>
or other naming
philipp64 has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: Ansuel: I have an ipq807x device - nbg7815; if I can help testing or whatever, simply ask me directly. I'm not too worried about bricking it... as I expressed in multiple occasions, my problem with contributing more is related to physical feasibility.
<Ansuel>
btw robimarko the user probably is using an old wifi offload build
<Ansuel>
the bad upload speed are very suspect
<Ansuel>
matches wifi offload badly configured
<russell-->
this works: sudo /usr/sbin/sshd -p22222 -oKexAlgorithms=+diffie-hellman-group1-sha1 -ohostkeyalgorithms=+ssh-rsa -ociphers=+3des-cbc
goliath has quit [Quit: SIGSEGV]
<robimarko>
mrkiko: Thanks, there isnt really anything to test currently, but if safexcell driver works that will need testing
<robimarko>
Ansuel: That is why I just dont bother anymore as its always something weird, changed u-boot, xwrt
<robimarko>
Immortalwrt, coolsnowolf-lede etc
<Ansuel>
wonder if they merged stuff from our repo
<mrkiko>
robimarko: safexcell' What does it do?
<mrkiko>
robimarko: but if there was an u-boot with tftp recovery or something, I would be very tempted. But only after geetting your approval :D
<Ansuel>
we waste time on other stuff than custom uboot hahaha
<mrkiko>
Ansuel: well, in cases like RT3200 it makes lots of sense. But also because we have the code and the advantages it brings are clearly huge. But then I understand that if you have custom u-boot of which you don't know the behaviour, problems may arise from that and hunting down bugs can be trickier
cmonroe_ has joined #openwrt-devel
bluew has joined #openwrt-devel
<f00b4r0>
more pressure to release on the m-l, *sigh*
<Habbie>
the release goals?
<f00b4r0>
aye
<Habbie>
i have to say it made me curious too
<slh>
mrkiko: the problem with custom u-boot (aside from yet another set of bugs), is that Xiaomi's u-boot does some weird stuff (life patching of variables), which the DTS needs to account for - if you now have a u-boot that doesn't do all this crap, the DTS tailored for xiaomi will have problems
<mrkiko>
slh: sure, I understand
<mrkiko>
slh: at some point there where problems like that with mtk mt7621 if I remember correctly
<slh>
there have always been issues with custom bootloaders in the past (even ubootmod on ath79), but those have been rather far and apart - with the way xiaomi has set up theirs, it's pretty guaranteed on day one
<mrkiko>
slh: but, to be sure I understand correctly, in cases like the RT3200 or ubootmod for AX6000, where we have the code and it's includeable in openwrt, it's fine
<slh>
rt3200, yes - for the simple reason that it's (almost) the only way to run OpenWrt in the first place, so it will get the daily testing needed
<slh>
ax6000 I'm not following that closely
<slh>
in the end, it's all a question of how much testing it gets with OpenWrt
<mrkiko>
slh: as you already know, whatever makes recovery easiest is something I whould ponder ... but I can understand every new or changed bootloader is similar to another device to support in a sense
<mrkiko>
slh: sure
<Ansuel>
also with custom uboot you totally drop support for reverting to stock
<slh>
pretty much, yes
srslypascal has joined #openwrt-devel
<mrkiko>
slh: Ansuel: sure
<slh>
and, especially if you look at the rt3200, you get a lot of users who think they'd need to upgrade their u-boot every time they sysupgrade, with an accordingly huge bricking potential
wo0f has joined #openwrt-devel
<wo0f>
join #openwrt-adm
<mrkiko>
slh: eh, I've seen.
<wo0f>
./slap wo0f
floof58 is now known as Guest2316
floof58 has joined #openwrt-devel
<Borromini>
f00b4r0: why is that pressure?
<f00b4r0>
...
<mrkiko>
slh: I understand those points, but then you know my opinion :D
<mrkiko>
Ansuel: sorry, forgot to include you in the "nicks"
<Borromini>
i mean: I understand the feeling. But why would one give in? :P
<Borromini>
i wouldn't mind 23.xx too but I suppose there are blockers still, plenty not to branch it yet
<f00b4r0>
that's not what I'm worried about
Guest2316 has quit [Ping timeout: 480 seconds]
<slh>
mrkiko: don't get me wrong, recovery can always be better (and I don't really like opening those pesky cases, with all those damned clamps and then soldering half-shut holes filled with RoHS solder, after taking off antennas, coolers, etc. at all - at least not on 'production' devices)
<Borromini>
f00b4r0: ok then what are you worried about (honest question, I am simply curious)?
<f00b4r0>
what I'm worried about is the fact that a new release means R-2 becomes EOL and we shed a ton of hardware which becomes landfill material.
<Borromini>
ah.
<mrkiko>
slh: Ansuel: but I understand your points yes. And have to agree mostly, because you never know what kinds of bugs an u-boot initializing the hw differently or not initializing can cause
<slh>
the problem with xiaomi also is, that we don't have their source - so no reference
<mrkiko>
slh: clear
<slh>
just guessing how to do it (still possible, but just more risky)
zatwai_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<mrkiko>
slh: yeah, for me a different recovery mechanism can have a huge impact - sending the device to soemone, aiting, and so on. But yes, these are all valid points I guess
<slh>
I think (don't have the device myself), the dynalink is relatively easy to open and has a populated serial header, so that should be rather easy to fit with a permanent serial plug
<robimarko>
f00b4r0: No way around that
<f00b4r0>
robimarko: yes way. Less frequent releases, and/or LTS releases
<f00b4r0>
(the latter had been suggested by Florian on the m-l quite a while ago)
<robimarko>
I mean, its one release per year, you cant do less than that
<robimarko>
And LTS boils down to manpower
<mrkiko>
slh: may I PM?
<slh>
mrkiko: sure
<f00b4r0>
robimarko: you certainly can do less than one release per year :)
<f00b4r0>
in fact, I would contend the release quality would increase, instead of the decreasing trend I seem to have noticed.
<robimarko>
How so?
<robimarko>
By increasing the number of backports and pain of adding new kernel features?
<f00b4r0>
no, by having a more polished and fully tested .0. Need I point out what happened for 22.03? ;)
<robimarko>
That was pretty much self-inflicted
<f00b4r0>
anyway, I know the tradeoffs. It just seems we're aiming for more bleeding edge support where I feel (but I know that's only my opinion) we should focus more on the hardware that mfg aren't supporting anymore.
<f00b4r0>
since (imho) that's were we really make a difference.
<robimarko>
Sadly, but we are not bleeding edge in any sense
<robimarko>
For you the goal is to keep old devices alive
<robimarko>
For me its not to run vendor crap, I just refuse to do so
<f00b4r0>
also imho most average users aren't keen to doing big upgrades ever so often for devices like routers.
<f00b4r0>
I share that goal. I just don't mind using older devices to achieve it, whereas you do mind :)
<robimarko>
I mind as they are not up to what I need
<robimarko>
Issue is that average user is not the one maintaing and keeping this thing alive
<robimarko>
Put yourself in my perspective, to push things upstream I currently have to have a linux-next buildroot
<robimarko>
And 5.15 openwrt that I then do the double work of backporting that
<f00b4r0>
you do realize no stable linux distro runs linux-next, let alone ToT kernel?
<f00b4r0>
because it's a dead end.
<f00b4r0>
I mean, that's exactly why LTS kernels exist.
<robimarko>
I dont want OpenWrt to run linux-next
<robimarko>
But forcing everybody to do the work twice as we are 6 versions behind is not easy
<robimarko>
LTS kernels are great if your stuff is upstream, but otherwise they are not fun
<f00b4r0>
that's because what we're doing (supporting new(ish) devices with LTS kernels) doesn't gel.
<f00b4r0>
hence my advocating for not putting so much focus on that.
<robimarko>
So the solution is to not support anything new?
<mrkiko>
f00b4r0: but the problem is - it takes time and effort to support things like ipq807x, and only if you start running soon you'll end up having enough knowledge when the thing is little bit more known, and old. Look at how it went with ipq4xx...
<f00b4r0>
new stuff can live in snapshot, because imho that's what most power users run *anyway*. e.g. do you ever run a release on your devices? I guess not :)
<robimarko>
I actually do, on one AP
<f00b4r0>
lol
<mrkiko>
f00b4r0: on the other hand I can understand your point. The fact is openwrt tries to keep the same kernel for all targets (otherwise we get crazy), but different targets have different development pace
<f00b4r0>
well I'm checkmated. My argument collapses in the wake of this new piece of evidence :)
<robimarko>
I get what you are trying to point out
<f00b4r0>
i know you do.
<robimarko>
But it always boils down to everybody working on what they want
<f00b4r0>
and likewise I understand your position.
<f00b4r0>
exactly.
<robimarko>
Basically what this project needs is LTS where it would just receive security fixes and thats it
<robimarko>
That keep old HW alive
<dhewg>
are there stats which release dropped how many boards?
<f00b4r0>
robimarko: ack, that would float my boat :)
<robimarko>
But I already see whats going to happen, its gonna start lacking features
<f00b4r0>
dhewg: anything 4/32 is gone. 8/64 is becoming really tight.
<robimarko>
So then everybody will want to backport more and more and more
<robimarko>
Which for me kind of beats a point of a stable release
<f00b4r0>
robimarko: for most old(er) hardware, a release like 19.07 is perfectly fine. Put yourselves in the shoes of people running older devices, they don't care about shiny features. If they did, they'd buy up (if they can, which is another point).
<robimarko>
Then we are in understanding
<f00b4r0>
so if we'd say something like, 19.07 only gets say kernel, wireless and firewall security fixes, beyond that you're on your own, I think that would be perfectly ok.
<dhewg>
kernel has per lts version maintainers, outsource the problem
<robimarko>
Pretty much
<robimarko>
dhewg: To who?
<zorun>
in a way, this is what happens in practice already (thanks to Hauke in large part)
<f00b4r0>
and of course we shouldn't backport new features. That breaks the traditional release models. New releases "release" new features.
<dhewg>
I think I just a 19.07 volunteer :D
<dhewg>
+heard
<zorun>
19.07 branched in July 2019, 19.07.0 release in January 2020, 19.07.10 released in April 2022
<robimarko>
f00b4r0: Exactly, cause currently we are doing opposite of what most projects are doing
<robimarko>
Activelly adding features to a stable release
<f00b4r0>
robimarko: yeah, which I think is not helping us much.
<robimarko>
I agree, adding new devices to a stable release should be a big no-no
<Habbie>
oh, i thought -new- devices were fine
<Habbie>
because that doesn't break any existing setup
<f00b4r0>
I'd argue there might be a blurry line for variants or very simple devices (since I (ab)used that feature for mikrotik ones), but otherwise I agree yes
<robimarko>
Well, yeah if there is a new 99% identical revision
<robimarko>
But for LTS, even that shouldnt be the case
<f00b4r0>
I can see the rationale for that argument, yes.
<Borromini>
Habbie: no, clones are okay in general
<karlp>
adding new devices to stable has been done _all_ the time, for better or worse, that policy is well entrenched.
Borromini has quit [Quit: leaving]
dangole has quit [Remote host closed the connection]
<robimarko>
Ansuel: Well, not even the register offset is different
<Ansuel>
wait
<Ansuel>
it's all the same?
<robimarko>
Yeah
<Ansuel>
....
<Ansuel>
did you test just loading it?
<robimarko>
Its just that QCA used a stupid reg property to suit them
<Ansuel>
what if it's something like the regulator?
<Ansuel>
that have the same reg with different name
<robimarko>
I figured out the correct start, no idea about the start