Network connection problems
-
I did try Wireshark, but didn't see much of interest. Suddenly, packets couldn't be delivered. When the Duet came back online after a couple of minutes of being unreachable, it sent DHCP packets to acquire an IP address.
-
Hi tomasf
The Dell power supplies we use have been fine on out DuetWifi powered printers, I don't think that is the issue.
Its interesting that you saw the DuetWifi completely drop off the network (to the point that it had to require an IP address when it re-connected). This sounds different to the issue we had with an older firmware version where there were AJAX timeouts in the server but the network connection remained up. In the wireshark logs did you see an excessive amount of traffic from any other device - maybe flooding the network?
I know its a pain but another option is to temporarily disable other devices on the network and then bring them back on one by one to see if one causes the DuetWifi to start dropping out.
Finally another thing to try is to see if the network connection is maintained if there is a steady stream of traffic to the DuetWifi, you could try pinging it regularly (ie in windows use the -t flag on ping). This is not meant to be a fix but rather to try and see if the DuetWifi network connection remains established if there is a stream of traffic.
-
My office (at a large company you've heard of) does regular audits and scans to remove unauthorized access points, and won't allow anything but IT-managed devices to connect to the official wifi. It's all done via security certificates… I wouldn't know how to connect a device to the wifi myself if I wanted to. I wouldn't be able to use the Duet Wifi there without one of the non-wifi control options. I'd imagine that's fairly common in the corporate and government world.
In all the places I've worked with rules like this, you can't connect unapproved ethernet devices either.
If there is a wired connection, the printer can be kept off the real network and only used on a separate 3d printer network, with the PCs that slice and monitor, but without connecting to any other sensitive network.
With wifi, the same can be achieved but while broadcasting all the data. You keep thinking that a) this is a consumer application we're worried about and b) we're connecting everything to the same network we do our top-secret banking on…. no.
I don't understand why you keep trying to defend strawman scenarios when there is a perfectly legitimate need for a duet with no wifi. A consumer with an i3 in their basement? Yeah, who cares. The cases where it matters are fringe cases, and they are few and far between. This is why I'm willing to pay a premium for a wired version.
Also, the encryption is all fine and dandy, but as with all encryption standards, their weakest point is the human element. In the environments I'm concerned with, social engineering/espionage would be a real possibility, and much more efficient than a brute force cracking attempt. By requiring physical access, knowing a simple password and intercepting the broadcast would not be enough.
-
@bot:
With wifi, the same can be achieved but while broadcasting all the data. You keep thinking that a) this is a consumer application we're worried about and b) we're connecting everything to the same network we do our top-secret banking on…. no.
No, I don't "keep thinking that". I've given examples of how WPA2-AES meets standards for both medical and military/DoD use. What other "fringe case" are you considering?
@bot:
Also, the encryption is all fine and dandy, but as with all encryption standards, their weakest point is the human element. In the environments I'm concerned with, social engineering/espionage would be a real possibility, and much more efficient than a brute force cracking attempt. By requiring physical access, knowing a simple password and intercepting the broadcast would not be enough.
Why would the password be allowed to be simple?
Espionage of the wifi password is a "real possibility", but espionage of the STL isn't?
Wifi only broadcasts a couple hundred feet indoors. If you're that close to a printer in a military building, you've already been cleared by security.
All of this is a moot point with RCarlyle's suggestion anyway.
-
There sure is an awful lot of speculation going on in this wired vs WiFi argument when it comes to security. For what it's worth, I manage my companies' global WiFi infrastructure and in my opinion any modern WiFi deployment can be just as secure as your average Ethernet port if not more so. In addition to run-of-the-mill WPA, any commercial access point will support 802.1x EAP certificates (sometimes even issued in the form of physical smart cards providided after gaining security clearance) as well as putting every client on their own NAT segment so they can't even see or communicate with other clients connected to the same WiFi network. Small business/commercial WiFi security has become INCREDIBLY robust in recent years and if deployed by someone who knows what their doing should be the least of anyone's worries.
And please pardon any typos, I typed this on my cell phone…
-
My only experience comes from surveillance, where there was absolutely no wifi anything allowed as part of the network attached to sensitive information. I don't have a deep knowledge of the technical aspects, only of the operational requirements of certain security-sensitive environments.
The distance traveled through a building is certainly a valid defense against attack, but perhaps printers are not being deployed in buildings, but tents.
-
You're arguing the most obscure edge case type stuff I've ever seen. Who's deploying a printer in a tent? Why would someone be so concerned with cracking into a secure network to get at a 3d printer when theres all the other stuff thats probably at least 10X more interesting? What world are you living in where thats something someone would be interested in doing?
Also, why are you arguing against the duet having wifi? T3P3 has already expressed interest in making a wired duet, like a potentially drop in replacement for the ESP module. Theres already been 2 wired Duets, just be patient.
-
Really sorry to have expressed an opinion.
I have 2 wifi's on the way, and a third in a close relative's machine as well… but I simply would have preferred to not have to rely on Wifi. What;s the big deal about that? Why am I all of a sudden an asshole for having concerns?
-
People addressed your concerns with pretty satisfactory answers (and sources), they offered solutions to your issues, and yet you continued to argue the same points, or you moved to increasingly more obscure scenarios. You went from expressing valid concerns to grasping for straws as to why wifi is the worst thing and its probably going to abduct your kids when you're not looking. Its starting to feel like US Bottle Rockets on the SeeMe forums again, just continuing on and on for no reason. You're not an asshole bot, I'm just tired of you beating the horse.
-
My main concern is not nearly the security issue… it was not I who was beating the dead horse. The issue of wifi is not dead, it's a real issue. I make printers for professional use, and sometimes my clients want to buy the printers. I want to be able to offer them wired ethernet, end of story. If a client requires ethernet, they won't also enjoy the features of the duet wifi I guess, like the higher current rating on steppers. I merely entertained the discussion about security concerns because, to me, that sort of thing is interesting.
-
Pronterface:
[[language]] >>> M552 S1 SENDING:M552 S1 WiFi server starting up DuetWiFiServer version 1.03 (ch fork) Flash size 4194304, free RAM 32840 bytes, WiFi Vcc 3.04V, host name: duetwifi, reset reason: Turned on by main processor WiFi server connected to access point XXXXXXX, IP=XXX.XXX.XXX.XXX, signal strength=-89dBm
Pinging works. However when I try to access the DWC I get the following crash:
[[language]] DuetWiFiServer version 1.03 (ch fork) Flash size 4194304, free RAM 32840 bytes, WiFi Vcc 3.03V, host name: duetwifi, reset reason: Exception WiFi server connected to access point XXXXXXX, IP=XXX.XXX.XXX.XXX, signal strength=-89dBm
M122 didn't give much information. It could be the weak signal strength. I have no other choice…
+1 for DuetWifi AP mode.It's a pity I still have severe wifi issues. IMHO that's the weakest part of the DuetWifi.
Thanks for any help! -
Yes -89dbm is a very weak signal. One option is to install a WiFi repeater closer to the Duet than your router is. Depending on what router you have already, another option may be to get a better router, especially if your existing one doesn't have MIMO capability.
We recognise that for a minority of users, wired Ethernet is preferable to WiFi. I have spent much of today working on the firmware for the forthcoming Duet Ethernet.
-
would it be possible to upgrade from wifi to ethernet ? like just replacing the esp module by an ethernet module ?
-
The prototype I am working with is a converted Duet WiFi. So If our plans work out as we hope, it should be possibe to convert a blue production Duet WiFi board to Ethernet. You would need a hot air desoldering too to remove the WiFi module.
-
That's great news!
Would a access point mode work for the DuetWiFi if more people needed it?I already tried some kind of repeater configuration by using an old router, which worked very well with other wifi devices. With the Duet WiFi I get the same behaviour I described above (only pinging works).
-
Yes we're planning to support running the Duet WiFi in access point mode.
-
I took my plain DuetWifi board, a usb cable and a laptop to a brand new access point.
The signal strength is around -40dBm.
Same problem again.Did you see my VCC reading? It's 3.04V. Could that be a problem? I saw other boards have around 3.3V.
-
If the Vcc really is only 3.03V then that could be a problem. However, that reading is taken by the ESP module itself, so it is only as accurate as the voltage reference in the module- which probably has a tolerance of 10% or so.
If the wifi server code keeps resetting with an exception, that suggests a bug in the server code, or possibly a hardware problem. But it's hard to diagnose a crash when we can't reproduce it, especially when we are dependent on 3rd-party code and not all the source is available.
-
Flash size 4194304, free RAM 32808 bytes, WiFi Vcc 3.21V, host name: duetwifi, reset reason: Exception
I can easily reproduce this by connecting to the web interface from both my computer (chromium) and my phone(firefox) and trying to move head from the machine control tab.
-
You are right with the 10% tolerance.
My DMM showed 3.29V between +3.3V and GND on the ESP8266 module.I tried different server versions:
DuetWiFiServer version 1.02 shows VCC 3.30V
DuetWiFiServer version 1.03 (ch fork) shows VCC 3.04VThe micro sd card shouldn't influence the web server. I also tried without micro sd card. No change.
@dc42: What third-party code do you mean? I only found this for the server: https://github.com/dc42/RepRapFirmware/blob/dev/src/DuetNG/DuetWiFi/Webserver.cpp
@lolorc: What's your signal strength? Does it work for you with only one device connected?