<Mangix>
ynezz: that thing is related to a ramips dlink device with a camera. IIRC the patch adding the camera support was removed in a kernel update. Probably hasn't worked in forever to be honest.
sestowner has joined #openwrt-devel
<hell__>
router with camera? or is it another kind of embedded device?
<jow>
It's one of those "brada" commits, hard to decipher but usually worthwhile
<jow>
nbd, maybe?
<f00b4r0>
so according to kernel docs the default is 3, and this is what it says:
<f00b4r0>
"Maximum number of packets that can be retransmitted without received an (acceptable) ACK from the destination. If this number is reached, a shorter timer will be started."
<f00b4r0>
so the title of the PR is completely misleading as this would affect all tcp flows
tohojo has joined #openwrt-devel
<f00b4r0>
and it basically relaxes the kernel default a bit
<f00b4r0>
jow: i'd say the main issues are misleading commit message (I don't see the connection with "dont wrongly interpret first-time packets as retransmits") and it doesn't say what actual issue it's trying to solve
<f00b4r0>
seems like a local fix for his particular setup that he wants to generalize, imho
<jow>
antonkh: that packages drops a whole load of geoip-shell-xxx.sh executables into $PATH
<jow>
most of them look like internal commands, consider moving those to /usr/libexec/ instead, which is meant for non-interactive executables
<antonkh>
ok, will do
<jow>
non-interactive as in not meant to be used by humans, but only by other executables
<antonkh>
they are usable by humans but you are correct, typically a human won't need to use them
<jow>
yeah, seen iut now after skimming the docs
<jow>
that's a lot of entry points
<antonkh>
wdym by entry points?
<antonkh>
as in lots of info? ye, I'm perhaps a bit overzealous on documenting
<jow>
did you ever consider (maybe for a later version) to bundle all those in a single geoip-shell command? You could translate commands like "geoip-shell install ..." to "/usr/libexec/geoip-shell-install.sh ..." invocations
<jow>
no entry points as in a lot of top level executables doing things with the geoip state
<jow>
compare with e.g. the "ip" or "iw" commands
<antonkh>
ye I understand
<jow>
there isn't a /usr/bin/ip-route, /usr/bin/ip-rule, /usr/bin/ip-link, ... but rather a /usr/bin/ip with various subcommands
<antonkh>
I opted for a modular design because the app performs several easily separatable tasks and this helps to keep each script size down
<jow>
if all those geoip-shell-xxx.sh commands are indeed "public" commands (as they seem to be, according to the docs) then disregard my /usr/libexec/ remark
<antonkh>
they are but public but they don't have to be polluting the $PATH
<jow>
anyhow, I've the feeling that I am bikeshedding again already, as it stands it looks fine
<jow>
f00b4r0: thanks for the opinion. Yeah, the submitter is deep into flowtable semantics, so this sysctl tweaking PR probably stems from that
<antonkh>
@jow you think it's good to go? I'm not in a rush if you wanna take a closer look into the code. I just want to get moving :)
<antonkh>
*to get it
<jow>
yes, it looks good to go
<antonkh>
great
<antonkh>
would be fantastic
<jow>
merged.
<antonkh>
yay!!!
<antonkh>
thank you :)
nixuser has quit [Remote host closed the connection]
<jow>
will hopefully submit the completed library soon
<schmars[m]>
pretty cool API, nice
rsalvaterra has quit []
<f00b4r0>
jow: btw speaking of ucode, if you could backport 08639a5e47d8ec2d78693493924081d841601028 to 23.05 so we get these fixes there it would be great. thanks :)
<f00b4r0>
s/backport/cherry-pick/
<svanheule>
mirko: on my GS1900-48 it blows out air
<mirko>
svanheule: any idea/effort/solution on measuring the RPMs of the fan so far?
<mirko>
it's a simple PWM signal (seen ion scope) - i think it was originally spect by intel, though 2 wires are swapped on the GS1900
castiel652 has joined #openwrt-devel
<castiel652>
\x: my department was working on a similar product but with 2G ram :D
uyguremre has joined #openwrt-devel
<f00b4r0>
mrkiko: if it's traditional intel 3-wire then it needs a 25kHz PWM signal
<f00b4r0>
s/mrkiko/mirko/
<mirko>
f00b4r0: it's not about controlling it, it's reading the RPMs
<f00b4r0>
ah sorry
<mirko>
controlling is usually 4 wire (VCC/GND/RPM(out)/PWM(in))
<f00b4r0>
iirc it's N pulses per rotation then, not pwm
<mirko>
just wondering if there's already some info on which gpio is used for RPM of the fan inside the GS1900 units
<f00b4r0>
usually N=2 if memory serves me right
<mirko>
f00b4r0: ah, ok, at least on the scope it pretty much looks like PWM-like (RPM-signal from the fan)
<f00b4r0>
it should be square pulses
<f00b4r0>
fed on an open collector output, typically
<mirko>
i was hoping to just use some existing device-tree node and attach it to whatever GPIO of the SoC and have a number indicating rounds per minute of the fan :)
<f00b4r0>
heh, dunno if that exists. It shouldn't be super hard. Presumably the gpio must be configured as a pulled-up input
goetz has quit [Remote host closed the connection]
<mirko>
cmonroe: it's interestig, but this is also about setting fan speed (via PWM) and not reading the RPMs the fan is actually spinning
<mirko>
also we still need to know which GPIO is used on the target, meaning, which GPIO of the realtek SoC is used in the zyxel gs1900 device
<cmonroe>
oops, sorry I read it backwards :) in that case a few lines above where I linked might help once you find the correct GPIO.
<mirko>
cmonroe: oh, where?
<cmonroe>
starting at line 90. pwm pin #1 is used for the fan and cooling-levels map to PWM values for duty cycle. the cooling-maps/trips starting at 127 define thresholds to select different duty cycles.