You are right, my issue is that I did not get this far. I'm still having authentication issues. I cannot use neither wget nor curl, so I have to do everything manually.
Looking at wget's auth-no-challenge implementation, it seems all it does is set basic auth headers, which we already do. Yet my client that works with LPDAAC and GSFC does not work with your server. Can you say more what's different about your setup?
Since I have no idea what LP or GES-DISC (I assume you meant them or maybe you meant LAADS, anyway we're three are at GSFC...OK there is a fourth CDDIS...) are doing, I can't say what is different.
It's not a complicated process. Requests are redirected to EarthData Login, once verified, they redirect back to us. That part cannot be any different for LP or GES-DISC or LAADS
Have you looked at the python script we made available on our download_methods page?
obdaac_download.pyscript have been reliable. Both wget and curl suffer with the added complexity needed to support legacy protocols and sign-on mechanisms. Wget sometimes tries to use IPv6 (based on DNS replies), then reports no route to host. If you are behind some sort of enterprise firewall, there may be tweaks in place for other sites using the EarthData SSO.
You need to work with your IT people. In the past, one connectivity problem was resolved after high level IT people talked to Goddard's IT people and were able to pinpoint a configuration problem with a router (controlled by a 3rd party) along one path to Goddard. Getting to the right IT people in a large enterprise can be tricky as there may be several layers of support people who follow their script: "if it works in Windows Explorer then your linux is not configured properly and we don't support linux so it isn't our problem". It may help to compare debugging output for a server that works and one that fails. Such output may be enough to get past the scripted IT support levels.