Opened 7 years ago
Last modified 7 years ago
#4582 new defect
non working fallback to ipv4 and bindwait delay problem on SH4 system without ipv6 and with OSCam with compiled ipv6
Reported by: | AbrahaM | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | General |
Severity: | medium | Keywords: | broken fallback ipv4 ipv6 bindwait delay |
Cc: | Sensitive: | no |
Description
Revision
all known including current (r11359)
Issue Description
on SH4 system, without ipv6 but with OSCam with ipv6 compiled, OSCam is delaying start for n*bindwait, where n = numer of protocols, if there are two protocols, and there is default (120) bindwait, start will be delayed by 240 secodns.
Issue confirmed personaly for cs378x, cs357x and for cccam by another tester. WEBIF is started correctly (immadietly).
When the issue occurs
always
How the issue is reproducable
by running OSCam binary with ipv6 supprot on SH4 system without ipv6 support
Attachments (2)
Change History (4)
by , 7 years ago
comment:1 by , 7 years ago
result in log on server side is:
2017-02-13 21:57:17 00000000 s (net) cs357x: Cannot create socket (errno=97: Address family not supported by protocol) 2017-02-13 21:57:17 00000000 s (net) cs357x: Trying fallback to IPv4 2017-02-13 21:57:17 00000000 s (net) cs357x: setsockopt(IPV6_V6ONLY) failed (errno=92: Protocol not available) 2017-02-13 21:57:17 00000000 s (net) cs357x: Bind request failed (Invalid argument), giving up 2017-02-13 21:57:17 00000000 s (net) cs378x: Cannot create socket (errno=97: Address family not supported by protocol) 2017-02-13 21:57:17 00000000 s (net) cs378x: Trying fallback to IPv4 2017-02-13 21:57:17 00000000 s (net) cs378x: setsockopt(IPV6_V6ONLY) failed (errno=92: Protocol not available) 2017-02-13 21:57:17 00000000 s (net) cs378x: Bind request failed (Invalid argument), giving up
in practice, server-port (tested on cs357x and cs378x) seems to be in undeterminitic state, client is reporting connection state as "UNKNOWN", and after attept to view livelog client-OSCam hungs for several seconds, and later is working noticeablhy slower. On server-side there is no trace of login attempts.
Testing something...
yup.
I was partialy wrong on issue description. Before tryfix ports where not working too, but there was delay. After tryfix there is no delay, but still (was before too) fallback to ipv4 is broken.
comment:2 by , 7 years ago
Keywords: | broken fallback ipv4 added; + removed |
---|---|
Summary: | bindwait delay problem on SH4 system without ipv6 and with OSCam with compiled ipv6 → non working fallback to ipv4 and bindwait delay problem on SH4 system without ipv6 and with OSCam with compiled ipv6 |
log on loglevel 255