1 |
Am Sat, 4 Mar 2017 16:42:07 +0000 (UTC) |
2 |
schrieb Grant Edwards <grant.b.edwards@×××××.com>: |
3 |
|
4 |
> On 2017-03-04, Kai Krakow <hurikhan77@×××××.com> wrote: |
5 |
> > Am Sat, 04 Mar 2017 08:02:11 +0000 schrieb "J. Roeleveld" |
6 |
> > <joost@××××××××.org>: |
7 |
> >> |
8 |
> [...] |
9 |
> [...] |
10 |
> [...] |
11 |
> [...] |
12 |
> [...] |
13 |
> [...] |
14 |
> [...] |
15 |
> [...] |
16 |
> [...] |
17 |
> [...] |
18 |
> [...] |
19 |
> >> |
20 |
> [...] |
21 |
> >> |
22 |
> >> Are other hosts linux or windows? |
23 |
> |
24 |
> Other Linux and Windows clients don't seem to be having this problem. |
25 |
> |
26 |
> >> Maybe a dodgy switch forgetting the correct path? |
27 |
> |
28 |
> I don't think so. I can ping the host while the CIFS subsystem says |
29 |
> "host is down". If the switch is forgetting the path, who's sending |
30 |
> back the SYN/ACK and the RST |
31 |
> |
32 |
> > Or an MTU problem... Is there a router in the path? |
33 |
> |
34 |
> Nope. |
35 |
|
36 |
The MTU idea was dumb anyways as you wrote that the problem occurs |
37 |
after some idle time... Which could still be a router problem - but as |
38 |
you wrote: no router. :-) |
39 |
|
40 |
> I'm going to try to set up a Wireshark capture in ring-buffer mode and |
41 |
> somehow detect the failure and stop the capture... |
42 |
|
43 |
Did something on the Windows side change? Maybe force Windows down to a |
44 |
lower SMB version or reduce/disable SMB client side caching? |
45 |
|
46 |
|
47 |
-- |
48 |
Regards, |
49 |
Kai |
50 |
|
51 |
Replies to list-only preferred. |