Re: [OpenAFS] Networking AFS related problem

2022-02-04 Thread Harald Barth
> I actually solved the problem in a very dumb way. Turns out I had never
> rebooted my phone or cycle my mobile connection since the problem
> appeared. I just rebooted and the problem was gone.

Well, such things happen. I had a "home router" provided by my ISP at
some point in time which never got any firmware updates as the ISP
relied on router reboots for that to happen. And mine was on UPS and
did never reboot ever, so I did see errors which already were fixed
but did not have made it into my box. Took a while to find that one.

> Anyway, thank you everyone for all your help! It turned out to be kind
> of a waste of time, sorry for that.

Well, I hope we all learned a litte more about AFS UDP transport in
the process (Ok, Jeff, you already know everything ;-) ;-) ). I don't
feel that you wasted my time, it's a give and take.

Harald.
___
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Networking AFS related problem

2022-02-03 Thread Jeffrey E Altman
On 2/3/2022 2:42 AM, Harald Barth ([email protected]) wrote:
> Hi Jeff!
>
>> It is unlikely that an ISP is blocking UDP traffic.
> For some value of "ISP". I have been to Karolinska Institutet who did
> supply Internet through the same "eduroam" cooperation as my home
> university. However, the "AFS experience" was totally different
> as in "non existent" on that "eduroam" as they had implemented ...

I do not consider "eduroam" networks provided by member institutions 
to be an ISP.

Many academic institutions which provide public or guest wifi access 
block a broad range of services including RDP, VNC, SSH, SMTP, 
SUBMISSION (e-mail), CIFS, Kerberos, and more.  Several "eduroam" sites 
block AFS ports due so because they have internal AFS cells that they 
consider insecure and want to ensure that they cannot be accessed by the
public.  Such sites expect endusers of these service to VPN to their 
home institutions once they are on the network.

rx/tcp would not help in such situations although a rx/https alternative
would.

Jeffrey Altman



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OpenAFS] Networking AFS related problem

2022-02-02 Thread Harald Barth


Hi Jeff!

> It is unlikely that an ISP is blocking UDP traffic.

For some value of "ISP". I have been to Karolinska Institutet who did
supply Internet through the same "eduroam" cooperation as my home
university. However, the "AFS experience" was totally different
as in "non existent" on that "eduroam" as they had implemented ...

> The most likely
> causes are a poorly implemented firewall

...firewall rules which blocked most of the UDP ports.

> It has been reported[1] that more than half of the web browser
> connections from Chrome browers to Google's servers are performed
> using the UDP based QUIC protocol.

But I bet chrome will work around the situation "no UDP" to a much
greater extent than AFS.

Greetigs,
Harald.

___
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Networking AFS related problem

2022-02-02 Thread Jeffrey E Altman
On 2/2/2022 6:38 AM, Harald Barth ([email protected]) wrote:
> I guess your IP provider lives in the IT world of 2022 where "Internet
> service" consists of mostly TCP/HTTPS and definitely not UDP ;-)

It is unlikely that an ISP is blocking UDP traffic.   The most likely
causes are a poorly implemented firewall in a home router or an
organizational firewall that is blocking a range of IP addresses which
have been used in prior attacks.

UDP is not only used for DNS and Kerberos but also for QUIC.  It has
been reported[1] that more than half of the web browser connections from
Chrome browers to Google's servers are performed using the UDP based
QUIC protocol.

Jeffrey Altman

[1]
https://techcrunch.com/2015/04/18/google-wants-to-speed-up-the-web-with-its-quic-protocol/



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OpenAFS] Networking AFS related problem

2022-02-02 Thread Harald Barth


Yes, the first packets are quite small until you start to actually
transfer chunks of files.

If you don't see any traffic coming back then something is
blocking On the server (the VLDB server(s) would be the first ones
to be contacted as you see) you can see if outgoing or incoming is
blocked.

If NAT is involved, i can be broken NAT as well.

I guess your IP provider lives in the IT world of 2022 where "Internet
service" consists of mostly TCP/HTTPS and definitely not UDP ;-)

Harald.
___
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Networking AFS related problem

2022-02-02 Thread Harald Barth


> Since AFS is working perfectly as soon as I change my WiFi connection
> to other connections, and the cell is perfectly reachable via a remote
> machine, I think the problem is with my ISP, but I don't have enough
> knowledge about AFS or networking to pinpoint the problem precisely.
> (Of course, "normal" web browsing is perfectly okay even with this
> problematic connection.)

Whem this occurs, then I am always reminded that AFS uses UDP over
it's own ports and not TCP with http or https.

> I would be very grateful if anyone can help me gather some more
> debugging info about this problem so I can give it to my ISP for them
> to fix it.

I would start with wireshark and filter on UDP ports 7000 and 7001,
then look if the packets are going out and if you get answers back
from the file servers and if you do if they are complete. Sometimes
bad networks drop or truncate UDP packets (either in or out) and if
they only truncate them, it can help to make your MTU size smaller, so
that not all default 1500 bytes are used. I test like 1400, 1200, ..
Restart afsd with additional parameter -rxmaxmtu SIZE.

Good luck,
Harald.
___
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info