Is there a good tftp client for Microsoft Windows to log into a router?

Start : Run : Control Programs and Features Windows Features Tick the "TFTP Client" box, then wait

I can see that on Windows 11 Home, and Win10 Pro.

That will download and install a tftp for you. And, it will come from Microsoft and be trusted, because the package will be signed with SHA2.

Paul

I would abandon that plan for your Netgear Nighthawk AC1900 Model R7000 and use http instead. Tftp is going to be problematic for you, while the router's GUI makes firmware updates extremely easy.

Use a web browser and log into the router by visiting one of the following destinations:

http://192.168.1.1

Next, browse to ADVANCED > Administration > Router Update, and press the Check button. The router will look for an updated firmware and offer to download it for you. Alternatively, if you've already downloaded the firmware that you'd like to use, click the Browse button on that page and navigate to the downloaded firmware. Upload the new firmware to the router and apply it.

The R7000 User Manual and other documents are located here:

I solved it but I can't really say what specific action solved it because almost everything made no sense because it all "should" have been working.

I had two main problems, one of which is the router stopped accepting the login/password for reasons unknown to me and the second was that as a result of that first problem (which had nothing to do with Firefox), I did a (whole bunch of) factory resets to try to log into the router, but that's when the Firefox wouldn't let me log in and wouldn't let me choose to not worry about the lack of a bona fide certificate either.

The solution should have come to me sooner, which was to use SRWare Iron (I didn't try any other browser than Iron so others may have worked also).

It's definitely a problem with Firefox though as there was ANOTHER problem which only showed up with Firefox, which was that I couldn't hit the "Apply" button whenever I changed some settings in Firfox, and yet I could hit that same "Apply" button when I switched to SRWare Iron to do it.

It could be my Firefox settings though, but what happened was a dialog box asking for an "OK" popped up in SRWare Iron, but not in Firefox.

I suspect it was something similar that prevented me from logging in also. But I don't know for sure why SRWARe Iron worked with http://192.168.1.1 but Firefox would never let me log in when I used a http://192.168.1.1 url.

In the end, I was able to flash the latest firmware from what appears to be from 12/13/1020 (R7000-V1.0.11.100_10.2.100.chk) to what is now version R7000-V1.0.11.136_10.2.120.chk from what appears to be 7/29/2022 based on these two reference urls I found in the Netgear download support site.

The great news is that after a few hours of repeating the same steps over and over and over (which is the definition of insanity anywhere else other than with routers), when I switched to SRWare Iron, things began working right because the hidden dialog boxes were popping up.

I don't blame Firefox because I'm sure I changed settings here and there based on what was suggested in this newsgroup in the past, but what I will do next time is switch browsers and tftp clients sooner than I did today.

The firmware recovery mode of most routers uses tftp only, I believe.

The problem I was having turned out to be, I think, that Firefox was hiding the dialog box which required an interaction from me, but SRWare Iron showed it. Without that dialog box, I couldn't log in with Firefox.

Since the first thing I did was press the reset button for seven seconds to factory reset, the IP, login & password should have been standardized. IP = 192.168.1.1, Login = admin, Password = password

The problem was the lack of the "s" in http because the router insisted on requiring a certificate but Firefox wouldn't let me say OK to anything.

The advantage of tftp is that you don't need to log into the router. So that's why I used tftp because I couldn't log into the router.

I was hoping the latest firmware would help, but I did so many things that I'm not sure in the end analysis what exactly made it finally work.

Two hardware questions that came up in this effort are about the USB ports and about the lack of an Ethernet port on my thin laptop.

For the Ethernet port, is there a way to convert the USB-A or USB-C or HDMI port into an Ethernet port so that I could have used that to log in?

And for the two USB ports on the router, one is USB 2.0 and the other is USB 3.0 where I seem to recall a security threat on them years ago.

Is it safe nowadays to put a USB stick into one of those two router ports so that I can access files from the Internet or is it still too dangerous?

You can always try a fresh profile in Firefox. You can do this easily by pulling up about:support in the URL-bar and clicking the "Refresh Firefox..." button. After you do this, "HTTPS-only" will be off by default, and all your other settings will be default as well.

If it doesn't help you, you can choose your old profile again by launching Firefox with the -P switch, which is the Profile Manager.

You can also just set up a test profile from the Profile Manger as well.

A company named ASIX makes USB to Ethernet chips. There is a USB2 version of chip and a USB3 version of chip. The USB3 version would be the more flexible version.

Then, another company, like Trendnet, makes the plastic USB casing for the adapter, with the ASIX chip inside. On the support web page, the driver name may have AX88179 as part of the filename, which is the ASIX Ethernet chip. There will be more than one company packaging up the ASIX chip and an RJ45 connector.

I also keep a Realtek 8139 network card here. This is reserved for OSes which are so crusty, that's the kind of networking card they support. Needless to say, I do not need that card too often, but it has come in handy occasionally when other stuff just would not work. Some OpenSolaris thing I tried, that's what I had to go get and plug in.

There are stories about sharing from the router being exploited too. You have to check in Google, whether your router has a known issue with this or not.

Just about anything that opens the NAT shielding on your IPV4 router, is a bad idea. Whether it is Port Forwarding to a designated machine inside your LAN, or it is the Port Forwarding that makes the USB stick visible from the WAN.

Sharing your NAS outside on the WAN, is also a bad idea. With Shodan around, snooping is practically automated, and your "secrets" don't stay secret for very long.

Paul

That sounds like a Firefox misconfiguration. Correcting that, or using any other browser, should have worked.

I don't think the router redirected you to https. The user manual says nothing about https and instructs the user to use http. Grab a copy of curl, or whatever tool you like, and see if the router is issuing an http redirect to https. I think you'll find that it's not. Instead, it's almost certainly a misconfigured Firefox, especially since you grabbed a second browser and it worked.

USB-C is easily adapted to Ethernet, but I'd remind you that WiFi works just fine. Yes, I know what the manual recommends but that doesn't change anything. You could have been using WiFi all along.

There's nothing inherently dangerous about the router's USB ports or a USB stick. The dangerous part is exposing your files to the Internet, just as the dangerous part is exposing the router's admin interface to the Internet. I wouldn't advise doing either of those things.

Yes, but with the tftp server on Windows and the router as the client.

In general I agree ... if you do anything (such as adblock, disabling javascript, changing settings like force https, etc) you have to be alert to the possibility that if something breaks, it's you that have broken it, and e.g. try firefox with a totally clean profile before blaming the router.

...

Maybe you had popups disabled in FF. That thing has hit me as well.

There is some other setting that will display a message bar at the top saying that "Firefox prevented the page from opening a pop up", and also displays a setting to change that. Like allowing popups on a certain site.

You are smarter than I am. But I regret what I just did to test you out.

In one way was just happy the ordeal was over, since the router went from being bricked to being unable to log in to working but without popups and then, finally, to reflashing and then working just fine outside Firefox.

I think you're all right the more I think about what happened, and, to test you all out, I actually made another huge mistake - and then regretted it!

I reset the router back to factory defaults, and tried again, and that's where I realized the problem was in the beginning when I noted that I could only access the unsecured http://192.168.1.1 once, and thereafter, not.

Remember I posted this screenshot showing the original firefox login issue?

I didn't post this in the first opening post because I didn't realize how important this screenshot below was, which is really telling me the issue.

The significance didn't occur to me until I pondered what you are saying.

In actuality, the sequence of events in Firefox was 49 happens before 48. That is, the login to http://192.168.1.1 actually works perfectly fine!

In fact, EVERY FIRST LOGIN to that unsecured IP address worked perfectly! (It's only what happened _after_ that login, where failures occurred.)

This important observation escaped me, until I re-tested things today. It's only slowly dawning upon me what actually transpired yesterday.

What I think happened, and I just tested it again, much to my regret, is the login to http://192.168.1.1 works fine, but the _next_ page (for whatever reason) requires the http(s) instead.

At that point, I suspect, some kind of Firefox protection (which I probably instituted long ago, I'm not going to deny I mess with the settings), prevented that _second_ page from doing whatever it wanted to do.

Only later, when the same kind of thing happened when I unchecked the router settings to broadcast the SSID did I then realize (by using Iron) that it was a hidden "OK" button that was preventing the next step.

All that is well and good, but what happened when I reset the router back to factory defaults just now is that it requested a new password.

No big deal, I thought. I'll just use the same 8-character password it took yesterday before I had upgraded the firmware with tftp clients.

Oh no! You can't do that! It _must_ now be a 10-character password, along with a whole bunch of other upper/lower case requirements.

Notice what happened, which is a _direct_ result of me resetting to factory defaults? Now I can't use the same password I've used on my other routers!

Unbeknownst to me, the new firmware _allowed_ the old password but the new firmware doesn't allow you to _set_ an old password after a factory reset.

So now, of all my routers, this one router has a different password. All because I tried to test what you were nicely telling me all along.

I should have just listened to you instead of testing it out for myself.

I like it! Thank you very much for that wonderful suggestion!

I won't know ahead of time if any given USB port will be USB2 or USB3, so if it "only" works with USB3 ports, isn't it _less_ flexible?

On the other hand, if it works with _both_ USB2 and USB3 ports when it says in the description that it's a USB3 device, then it _is_ more flexible.

But that's why I'm confused. Does that handy USB3-to-Ethernet device _also_ work with USB2 ports?

Good advice. I always take people up on any good advice they suggest.

Unfortunately, I'm "mad" at you for suggesting that advice, but only because I found out exactly what I did NOT want to find out about it!

The router is a Netgear R7000 which uses what they call "ReadySHARE", which is implicated in the NetUSB flaw based on this Netgear flaw page.

I don't remember the flaw from long ago so I googled for what it may be.

This first article I found says it's in ReadySHARE (also known as NetUSB) which incorporates the KCodes NetUSB software which has the flaw in it.

Googling further, I seem to remember a WAN flaw (open to the Internet), and not just a LAN flaw as the ReadyShare/NetUSB flaw above first seems to be.

Something like this is a LAN flaw only, but that's in an Archer router.

Googling more, I see the Readyshare/NetUSB flaw also affects the WAN.

For now, even after Googling, I can't tell if there are known flaws in USB implementation on a router, so I'll assume they've all been fixed.

Whatever it uses, I've always logged in by using https and telling it to update using a firmware file I've previously downloaded(and checked the SHA256). Exactly as Char Jackson described. Any browser I've tried (Firefox, Palemoon, even the old M$ bug-ridden offer) works. Been doing this for well over a decade. I don't trust the router to "update itself". It might have been hacked and download something nasty. []'s

USB3 ports on computers, have nine pins, and work in USB2 mode or USB3 mode.

Peripherals have nine pins as well. The TrendNet plugged into a USB2 port still works. It can run at GbE rate... but the USB2 connector makes a

USB2 ASIX chip = 10/100BT mode, no GbE (12MB/sec ethernet, 35MB/sec max phy) USB3 ASIX chip = GbE or less, (112MB/sec GbE, 35MB/sec GbE on USB2, 12MB/sec 10/100BT mode)

I would have to check the R7000 manual, to figure out what the difference is between the two USB connectors. They could be special purpose or general purpose.

On this web page, the USB stick goes in the front (USB3) port.

Hey buddy, good to see you still posting.

Thank you for looking. I didn't know anything about this until this week.

I think this whole https thing is a Netgear-only encumbrance which Netgear seems to have inserted into the initial login process that occurs only once

- which is the first login after you perform the 7-second factory reset.

If that assumption is correct, it was the inserted Netgear software that was trying to get to an http(s) server in order to set these options.

Pressing any button on that initial one-time-only page above is what brings you to an https link of

Thank you for clarifying that no such https setting exists in your R7000.

I've seen similar "web server" settings in some routers but as you said, it's usually the better non consumer routers that have web server setups.

Here's a user guide for one of those. Look on page 49 in "Chapter 7 Services" showing a graphic with a "Secure Server Port" default of "443" and an "Enabled" check box for "Secure Connection HTTPS" on by default.

Thank you for looking into the Netgear R7000 manual, which I had also read at the time I was trying to log in and it said nothing about this problem.

I had initially searched the Netgear KB before asking here for help.

I learned a lot but what I learned about tftp was that almost all my initial assumptions about tftp were wrong, I think in that I didn't realize that you can't actually "log in" using tftp. I think.

When I posted this thread, my plan was to log into the R7000 with tftp because I couldn't log into the router with http://192.168.1.1 because that one-time-only login referenced that https page, which Firefox wouldn't bring up the OK boxes to get past that Netgear inserted encumbrance.

But now that I've used tftp once, I think tftp does NOT log into the router. It just pushes new firmware to the router WITHOUT a log in.

Is that correct that tftp only moves files but can't log into the router? (Isn't that a potential security hole if somehow someone has tftp access?)

tftp doesn't push. It sits there, waiting. It is the client, ie, the router, who asks to download something from a tftp server (typically any one in the LAN).

AFAIK there is no login/pass in the protocol. Insecure.

Wait for the Power LED to light orange and start flashing.

When the Power LED is flashing, click Put in Tftpd64 to initiate the firmware upload. ^^^ The upload might take a few minutes.

If the firmware upload is successful, a dialog box appears to confirm the blocks transferred, with a 0 block retransmitted message and a MD5 checksum. If the firmware upload fails, repeat steps 8-11. "

This means the router has a TFTP daemon that runs during boot up. If an incoming TFTP connection is detected, the router knows you are attempting to "put" a file to it. That file, as long as certain details of it check out, will then be accepted.

Using the client tftp program which is part of Windows, would do the same thing.

The thing that threw me off, is TFTPD64 is actually a dual mode program. It contains a server daemon, as well as a TFTP client. Normally, you only name daemons with the letter D and my assumption was that the program was purely a TFTP server (a TFTPD).

It is running in client mode, as described in the procedure.

Paul