Search content
Sort by
Showing 20 of 201 results by Red_Wolf_2
And again, the return of the dreaded incessant beeping. Same errors again!
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.450000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.460000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.470000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.480000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.490000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.570000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.570000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.580000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.590000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.600000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.600000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Still no word from Bitmain... Is anyone else experiencing these errors?
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.450000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.460000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.470000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.480000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.490000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.570000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.570000] usb 1-1: clear tt 1 (9041) error -71
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.580000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.590000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.600000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Tue Aug 5 20:38:32 2014 kern.err kernel: [53274.600000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Still no word from Bitmain... Is anyone else experiencing these errors?
Couple of points for those who might be interested...
Connecting the blades up to non-specific controllers...
Not easy to do. The blades are driven by a specific microcontroller (PIC of some sort) which is connected via USB to the AR9331. All of this is integrated onto the mainboard, and can't be removed. It also limits the number of blades you can connect to two, as the MCU in question doesn't have any connectors for more and likely lacks the resources to support them anyway.
As for the controller, it is already pretty much maxed out and would probably not be able to handle more even with the room to connect them. If you could get the MCU without the AR9331 board and also programmed with the appropriate firmware, you might be able to get it running on a generic PC or other more powerful host. You would however need access to the driver to compile it for a different architecture (not impossible, but difficult).
People having issues with controller boards...
Why not do as I do and post extracts from system logs here? Those who have worked with linux, and specifically OpenWRT might be able to help out, or at least give more specific diagnosis of issues...
Connecting the blades up to non-specific controllers...
Not easy to do. The blades are driven by a specific microcontroller (PIC of some sort) which is connected via USB to the AR9331. All of this is integrated onto the mainboard, and can't be removed. It also limits the number of blades you can connect to two, as the MCU in question doesn't have any connectors for more and likely lacks the resources to support them anyway.
As for the controller, it is already pretty much maxed out and would probably not be able to handle more even with the room to connect them. If you could get the MCU without the AR9331 board and also programmed with the appropriate firmware, you might be able to get it running on a generic PC or other more powerful host. You would however need access to the driver to compile it for a different architecture (not impossible, but difficult).
People having issues with controller boards...
Why not do as I do and post extracts from system logs here? Those who have worked with linux, and specifically OpenWRT might be able to help out, or at least give more specific diagnosis of issues...
I am still looking to see if anybody else here has seen this when they try to log into their S3?
/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute function dispatcher target for entry '/'.
The called action terminated with an exception:
/usr/lib/lua/luci/sauth.lua:87: Session data invalid!
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function
I had logged on the miner a few times with no problem and this is what comes up when I try and log on now. The miner is still mining and if I log into it thru Putty I can still get into the frequency, so it seems the password is still working but i'm afraid of rebooting or using the reset button until I know I will not brick the miner. Bitmain has PM me that he turned it over to his engineer and I hope to hear something soon but was wondering if anybody else has seen this problem.
/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute function dispatcher target for entry '/'.
The called action terminated with an exception:
/usr/lib/lua/luci/sauth.lua:87: Session data invalid!
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function
I had logged on the miner a few times with no problem and this is what comes up when I try and log on now. The miner is still mining and if I log into it thru Putty I can still get into the frequency, so it seems the password is still working but i'm afraid of rebooting or using the reset button until I know I will not brick the miner. Bitmain has PM me that he turned it over to his engineer and I hope to hear something soon but was wondering if anybody else has seen this problem.
Tried /etc/init.d/uhttpd restart
It might give the process a kick to get it running again... The error you're seeing is to do with the web interface on the S3 screwing up when trying to handle the authentication, according to one bug report, when one process is writing to the session data at the same time another is reading it out. Does the error happen every single time, or just every so often?
And it happened again, sudden continuous beeping which was only fixed by a reboot.... Bitmain or anyone care to jump in and explain these?
Try a DSN of 8.8.8.8 if you are not already on it.
typo there
should be DNS (noobs: domain name service)
This isn't a DNS error. The error messages are related to the USB bus, and something dropping and not resetting correctly. Network settings are fine!
And it happened again, sudden continuous beeping which was only fixed by a reboot.... Bitmain or anyone care to jump in and explain these?
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.010000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.020000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.020000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.040000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.040000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.060000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.060000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.080000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.080000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.100000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.100000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.info kernel: [67039.120000] bitmain 1-1.1:1.0: USB Bitmain asic device now attached to USB Bitmain asic-0
Sun Aug 3 11:31:52 2014 kern.warn kernel: [67039.120000] PIC microchip usb OK
Sun Aug 3 11:33:01 2014 cron.info crond[574]: crond: USER root pid 12560 cmd /usr/bin/cgminer-monitor
Sun Aug 3 11:33:02 2014 kern.info kernel: [67109.770000] bitmain 1-1.1:1.0: USB Bitmain asic #0 now disconnected
Sun Aug 3 11:33:02 2014 kern.err kernel: [67109.780000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:02 2014 kern.err kernel: [67109.800000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.070000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.080000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.090000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.100000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.110000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.120000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.130000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.140000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.150000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.160000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.170000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.170000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.180000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.190000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.200000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.200000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.210000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.220000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.230000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.230000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.240000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.250000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.260000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.270000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.270000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.280000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.290000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.300000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.310000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.310000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.320000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.330000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.340000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.340000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.350000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.360000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.370000] hub 1-1:1.0: hub_port_status failed (err = -71)
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.010000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.020000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:51 2014 kern.err kernel: [67039.020000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.040000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.040000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.060000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.060000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.080000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.080000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.100000] usb 1-1: clear tt 1 (1041) error -71
Sun Aug 3 11:31:52 2014 kern.err kernel: [67039.100000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:31:52 2014 kern.info kernel: [67039.120000] bitmain 1-1.1:1.0: USB Bitmain asic device now attached to USB Bitmain asic-0
Sun Aug 3 11:31:52 2014 kern.warn kernel: [67039.120000] PIC microchip usb OK
Sun Aug 3 11:33:01 2014 cron.info crond[574]: crond: USER root pid 12560 cmd /usr/bin/cgminer-monitor
Sun Aug 3 11:33:02 2014 kern.info kernel: [67109.770000] bitmain 1-1.1:1.0: USB Bitmain asic #0 now disconnected
Sun Aug 3 11:33:02 2014 kern.err kernel: [67109.780000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:02 2014 kern.err kernel: [67109.800000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.070000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.080000] usb 1-1: clear tt 1 (8040) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.090000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.100000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.110000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.120000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.130000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.140000] usb 1-1: clear tt 1 (9041) error -71
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.150000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.160000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.170000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.170000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.180000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.190000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.200000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.200000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.210000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.220000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.230000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.230000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.240000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.250000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.260000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.270000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.270000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.280000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.290000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.300000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.310000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.310000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.320000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.330000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.340000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.340000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.350000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.360000] hub 1-1:1.0: cannot disable port 1 (err = -71)
Sun Aug 3 11:33:06 2014 kern.err kernel: [67113.370000] hub 1-1:1.0: hub_port_status failed (err = -71)
oh thats cool about the wifi, I have ordered few of the kits so lets see how that goes.
anyone installed one yet ? what dBi antenna did you get and how good is the reception at what distance?
anyone installed one yet ? what dBi antenna did you get and how good is the reception at what distance?
I've installed three. Had various antennas, usually between 3-5dbi. All perform perfectly well, coverage about equal to that of any other wifi device.
whats that wifi feature in the S3 ? can I use that instead of the LAN cable ? Or do I need something else to get it working?
Previous post several pages back.
Ha, I had 35-40 laptop antenna's I threw out a few months ago when I moved. Oh well, anyone who has access to an old scrap laptop could pull one out of there.
So....anyway...for those of you that offered meaningful advice...thank you. I ordered some of these
http://www.amazon.com/gp/product/B00DP64JRG/ref=ox_ya_os_product_refresh_T1
And will let you know what they do for WiFi reception when I get batch 5 miners and install. The U.fl pigtails and antenna combo is ridiculously inexpensive, so I figured I'f give them a whirl and share what happens on the forum.
Those pigtails and antennas should work perfectly. Three out of four of my S3s are on Wifi with antennas and pigtails fitted, I have found drilling the hole for the RP-SMA antenna to be a bit of work though, those cases are remarkably thick and tough!
Just had a rather odd situation occur...
One of my B1 S3s, running latest firmware decided to go beep crazy. Normally I'll get a beep or two and it'l stop, but this time it wouldn't.
Syslog showed the following:
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.600000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.610000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.620000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.710000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.720000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.730000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6774.830000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6774.840000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.410000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.420000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.420000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.510000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.510000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.520000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Issued a reset to CGMiner and it came back online, but anyone out there have any ideas what might have caused a USB issue on these? In theory it shouldn't be possible, as the whole USB infrastructure is on the mainboard (no loose plugs or anything).
One of my B1 S3s, running latest firmware decided to go beep crazy. Normally I'll get a beep or two and it'l stop, but this time it wouldn't.
Syslog showed the following:
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.600000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.610000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.620000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.710000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.720000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:19 2014 kern.err kernel: [ 6774.730000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6774.830000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6774.840000] usb 1-1: clear tt 1 (9041) error -71
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.410000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.420000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.420000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.510000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.510000] hub 1-1:1.0: cannot reset port 1 (err = -71)
Sat Aug 2 07:48:20 2014 kern.err kernel: [ 6775.520000] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad?
Issued a reset to CGMiner and it came back online, but anyone out there have any ideas what might have caused a USB issue on these? In theory it shouldn't be possible, as the whole USB infrastructure is on the mainboard (no loose plugs or anything).
Hey Bitmain, could you please get the documentation on chips, boards and protocol to the BFGMiner developers? I'd like to give it a try on my S3s but they say they still need documentation to write a suitable driver...
Thanks for the replies, i`ll give the google method a try!
I`ve just flashed the Ants with the latest firmware and so far, both units are doing 443 gh\s (2 hours in).
Even the one which would only do 420-430gh\s before. So, it can`t just be the beeping that they changed?
I`ve just flashed the Ants with the latest firmware and so far, both units are doing 443 gh\s (2 hours in).
Even the one which would only do 420-430gh\s before. So, it can`t just be the beeping that they changed?
What version of CGMiner is it now running?
1) What's up with the Wifi options in the networking tab? Is this for potential wifi expansion? Was surprised when I seemed to be able to connect o my wifi network with them, but ya must have 'connected' just through my wired connections. Anyways just want to make sure that there is no wifi right.
You need an antenna, but it has wifi built in.
Is the wifi set up the same as with the S1's? I don't see this anywhere in the doc nor do is see the SME connector in the pics. Just bought five S3s (batch 5) and have been running seven S1s on WiFi with absolutely no issues for months. Thought I was going to have to hardwire for the S3s, but would love to avoid doing so, if possible/practical. Is anyone actually running S3s on WiFi? If so, are there any issues to be aware of?
I'm running one S3 on wifi and another hard wired, but that's because it can't get the signal strong enough for the wifi where it has to be located for the time being. The one running wifi isn't using an antennae.
So does the S3 have an SMA connector for an antenna? It looks like this:
http://www.active-robots.com/right-angled-pcb-sma-connector
Yes but you have to open the case and keep it that way. They were too lazy/cheap to connect a pigtail.
i wonder if you could just drill a small hole
Hmmm...I know the case is critical to maintaining airflow / cooling, so I definitely don't want to take it off permanently. Depending on where the SMA connector is positioned, I might just try to drill a hole (probably not so small) in one, connect an antenna and see what happens to the temps. If anyone has a pic or can describe the position of the SMA connector, that would be very helpful. For example, is it in the same place as on the S1s? Thanks in advance.
Dumb question, but why would adding an antenna change the temps? Or do you mean drilling holes in the case will cool it better?
No...my concern is that drilling a hole in the case for an antenna will disrupt the airflow and INCREASE temps.
It most likely will not. These cases are not pressure optimized so I'm sure there is air escaping already?
OK...let's see how many pages we could fill with dump nonsense...continue, please...
ZiG
EDIT...: Obviously drilling a hole and installing a WiFi antenna is NOT changing the thermals / cooling of S3... OK...
"dump nonsense" as in your grammar?
a 1cm hole in this shroud will have no effect on a case that is not pressure optimize.
Do you know how positive and negative pressure works.
There are no gaskets on this case to seal anywhere to help with pressure, it is just air passing through it with high CFM.
Please don't insult other people when you are the one full of "dump nonsense"
You have to be clueless to think 1 cm hole in a NON-pressure optimized case will do more than a few degrees changing "the thermals / cooling of S3... OK...
"...While we're on this long page of quotes, anyone tried submerging one of these in oil to cool them yet?
1) What's up with the Wifi options in the networking tab? Is this for potential wifi expansion? Was surprised when I seemed to be able to connect o my wifi network with them, but ya must have 'connected' just through my wired connections. Anyways just want to make sure that there is no wifi right.
You need an antenna, but it has wifi built in.
Is the wifi set up the same as with the S1's? I don't see this anywhere in the doc nor do is see the SME connector in the pics. Just bought five S3s (batch 5) and have been running seven S1s on WiFi with absolutely no issues for months. Thought I was going to have to hardwire for the S3s, but would love to avoid doing so, if possible/practical. Is anyone actually running S3s on WiFi? If so, are there any issues to be aware of?
I'm running one S3 on wifi and another hard wired, but that's because it can't get the signal strong enough for the wifi where it has to be located for the time being. The one running wifi isn't using an antennae.
So does the S3 have an SMA connector for an antenna? It looks like this:
http://www.active-robots.com/right-angled-pcb-sma-connector
Yes but you have to open the case and keep it that way. They were too lazy/cheap to connect a pigtail.
i wonder if you could just drill a small hole
Hmmm...I know the case is critical to maintaining airflow / cooling, so I definitely don't want to take it off permanently. Depending on where the SMA connector is positioned, I might just try to drill a hole (probably not so small) in one, connect an antenna and see what happens to the temps. If anyone has a pic or can describe the position of the SMA connector, that would be very helpful. For example, is it in the same place as on the S1s? Thanks in advance.
Dumb question, but why would adding an antenna change the temps? Or do you mean drilling holes in the case will cool it better?
No...my concern is that drilling a hole in the case for an antenna will disrupt the airflow and INCREASE temps.
It won't.
This is the control board. The U.FL connector is on the top right corner of the blue board. The Green board is the bit which the RJ45 socket and lights are mounted on, and sits above the actual hashing boards. Drill an extra hole near (but not too close to) the existing holes on the fan plate and mount it there, or if you're feeling squeamish about drilling that nice pretty case
just peel off the sticker on the far end and make up a blank plate out of some card and mount the RP-SMA socket there instead.As for WiFi, I posted some pics way back when I got my B1 S3s (pretty sure I was the first! ), showing the controller board with the U.FL connector on it. Can't remember which page it was on but yes, I can confirm WiFi does work, and all you need is a pigtail and antenna. I was going to drill a hole but never got around to it, instead the pigtail is hanging out the same gap the fan wires come from. Might do a more permanent upgrade on my two new B4 units that will be coming my way.
Also, query for Bitmain:
Is the version of CGMiner on the units going to be upgraded any time soon? I'd love to see a more recent version of it or BFGMiner available, preferably one which doesn't absolutely kill the CPU usage on the controller board.
), showing the controller board with the U.FL connector on it. Can't remember which page it was on but yes, I can confirm WiFi does work, and all you need is a pigtail and antenna. I was going to drill a hole but never got around to it, instead the pigtail is hanging out the same gap the fan wires come from. Might do a more permanent upgrade on my two new B4 units that will be coming my way.Also, query for Bitmain:
Is the version of CGMiner on the units going to be upgraded any time soon? I'd love to see a more recent version of it or BFGMiner available, preferably one which doesn't absolutely kill the CPU usage on the controller board.
Has anyone run a network sniffer on these things while they are running. There is a lot more network noise than the S1's made. I am not talking about share request/response, I am talking about calls to hosts and socket connection responses(causing extra beep sounds), kind of like a bot.
I have the gift of always thinking the worst of people. Would it be possible a % of the hash power is utilized/reserved for an internal process named "4bitmainpool"?
Maybe its some debug/diagnose thing they forgot to take out?
I first used Fiddler to sniff but setting up a Unix VM for better tools now.
Imagine, what if they could take 2-4% hash power from every S3 miner on-line.............
I have the gift of always thinking the worst of people. Would it be possible a % of the hash power is utilized/reserved for an internal process named "4bitmainpool"?
Maybe its some debug/diagnose thing they forgot to take out?
I first used Fiddler to sniff but setting up a Unix VM for better tools now.
Imagine, what if they could take 2-4% hash power from every S3 miner on-line.............
Process list from the unit...
PID USER VSZ STAT COMMAND
1 root 1372 S /sbin/procd
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
5 root 0 SW< [kworker/0:0H]
7 root 0 SW< [khelper]
8 root 0 SW [kworker/u2:1]
60 root 0 SW< [writeback]
62 root 0 SW< [bioset]
64 root 0 SW< [kblockd]
89 root 0 SW [kworker/0:1]
94 root 0 SW [kswapd0]
139 root 0 SW [fsnotify_mark]
152 root 0 SW< [ath79-spi]
230 root 0 SW< [deferwq]
231 root 0 SW [kworker/0:2]
241 root 0 SW [khubd]
327 root 0 SWN [jffs2_gcd_mtd3]
381 root 880 S < ubusd
382 root 768 S /sbin/askfirst ttyATH0 /bin/ash --login
418 root 0 SW [kworker/u2:2]
456 root 0 SW< [cfg80211]
530 root 1492 S /sbin/netifd
574 root 1516 S /usr/sbin/crond -f -c /etc/crontabs -l 5
585 root 1156 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22
636 root 1500 S udhcpc -p /var/run/udhcpc-br-lan.pid -s /lib/netifd/dhcp.script -f -t 0 -i br-lan -C
637 root 1500 S udhcpc -p /var/run/udhcpc-eth1.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth1 -H antMinerS3 -C
656 root 1152 S /usr/sbin/uhttpd -f -h /www -r antMiner -x /cgi-bin -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0.0.0.0 80
684 nobody 956 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k
848 root 1596 S wpa_supplicant -B -P /var/run/wifi-wlan0.pid -D nl80211 -i wlan0 -c /var/run/wpa_supplicant-wlan0.conf
879 root 1508 S udhcpc -p /var/run/udhcpc-wlan0.pid -s /lib/netifd/dhcp.script -f -t 0 -i wlan0 -H antMinerS3 -C
951 root 1500 S /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.org -p 2.openwrt.pool.ntp.org -p 3.open
976 root 42780 R cgminer --bitmain-options 115200:32:8:18:218.75:1106 -o stratum+tcp:/// -O
995 root 1220 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22
996 root 1508 S -ash
1104 root 1496 R ps w
Bit unwise to make it capable of being hijacked if any old person can shell into the unit and play around, they'd be caught pretty quickly. More likely the traffic you're seeing could be from the ntp daemon.
Hi Bitmain,
Any word yet on updated firmware to resolve the beeping issue yet? Or a newer version of cgminer bundled with things? 3.12 seems to be six months out of date now, I'd be hoping there are some efficiency improvements by now...
Any word yet on updated firmware to resolve the beeping issue yet? Or a newer version of cgminer bundled with things? 3.12 seems to be six months out of date now, I'd be hoping there are some efficiency improvements by now...
Some comments:
1) Can't the beeper ringing be disabled on the configuration page by setting beeper to false?
1) Can't the beeper ringing be disabled on the configuration page by setting beeper to false?
Yep, set it to false and it still beeps randomly.
I got the Beeping sorted
Removed the casing 5 screws each side
speaker/beeper on the top
open it with a sharp blade and pulled out the round steel thingy
no more beeps
!!! The techie within me cries out in alarm... This is like removing the engine warning light to fix an engine problem!
If anyone wants to sort the beeping noise in a more appropriate way, I'd recommend the tape method. It will not stop the sound completely, but it will definitely deaden it. The intermittent beeps are purely a software issue, and will almost certainly be fixed in a future firmware release. I suspect its whatever is mixed in with CGMiner.
Seriously hoping that future firmware will improve CGMiner efficiency too, it bothers me seeing it load out the controller board as high as it does, and I reckon it would probably reduce reject rates too...
6. Change protocol from "Static Address" to DHCP client. Set an appropriate hostname (such as antMiner) then click Save and Apply.
What would be the advantage of DHCP vs static? With DHCP you will need to check it (IP) every time you want to login or ssh.
Not a big deal, of course, but why bother?
ive always done DHCP and my IP addys have never changed, even after reboots and shut down's to move hardware around the garage
Interesting, because my family iphones, ipads and laptops IPs are always rotating when on DHCP; same with PC that went for repair of the power source.
Once it came back-different IP, even completely out of previous range. Maybe it is different for miners.
Depends on lease length and how long the devices are away from the network. If the lease expires before the device reassociates and another device associates in the meantime, it will end up taking the IP and they will rotate. If however the devices aren't moving around much, they will just keep renewing their leases and keeping the same IPs.
6. Change protocol from "Static Address" to DHCP client. Set an appropriate hostname (such as antMiner) then click Save and Apply.
What would be the advantage of DHCP vs static? With DHCP you will need to check it (IP) every time you want to login or ssh.
Not a big deal, of course, but why bother?
In my case, I have IPs all handled from a central DHCP server. Prevents weird conflicts occurring and I can assign a static lease from the server to ensure a device always has the same IP if it really bothers me. Just a matter of personal choice, I find it a lot easier to administer given I have dozens of various devices running across a whole bunch of different private subnets...
This will enable the DHCP server. You don't want this. Instead change the protocol type from Static IP to DHCP Client and save and apply the changes.
Thanks for the info. I thought that that option looked suspect. That's why I asked in my first post if there was a DHCP Client option. Thanks for confirming that there is.
If anyone is interested, I'll put together a quick starter guide for anyone who wants to switch from the default settings to a dynamic assigned IP setup...
I think that I'm all set. But given that the set up is confusing, I think that it would be generally helpful to other people to keep them from messing up their units.
What an odd choice for Bitmain to expose all of this router functionality. It's more like setting up a firewall than a miner. Instead of suppressing this complexity and providing a mining appliance (which I suspect most people are interested in), they've exposed a bunch of stuff that people don't need.
The sense that I have is that under the hood the two blades are Ethernet devices and front end is a router for them. So I guess people could build out large scale farms made of many blades under one or more routers. Maybe in that case it would make sense to enable a DHCP server for the blades. But if anyone was building out that kind of infrastructure, I assume they'd be using their own router or firewall, not the one that comes with the S3.
So again; exposing this functionality is just an unnecessary complication. But they were probably in a rush to ship, so UI refinements were probably pretty low on the priority list
No problems
The reason all the router functionality is exposed is that the OS is OpenWRT, which is designed primarily for use on wireless routers. You can do a heck of a lot with it on a good quality router, and in the case of the S3 the controller board is really little more than a specialised wifi router board with some extra circuitry to allow it to talk to some USB devices. This appears on a cursory glance to be wired directly to a PIC32 microcontroller which has some glorified firmware on it that does the actual talking to the ASICs. I'd imagine this wouldn't be dissimilar to how the older BFL gear worked, with a MCU to handle all the discussion and job handing between the ASICs, and converting it all into a nicer format that gets shunted across the USB serial port set up between the AR9331 and PIC.
The blades themselves don't seem to talk as ethernet devices, they need that PIC in there to handle things properly.
Could probably make the blades as PCI-e cards if they really wanted to...
Ok, here is my quickstart guide. Please correct and make additions/removals/clarifications as required...
1. Plug up your power supplies to your AntMiner S3. Minimum of one PCI-e power connector per side (2 recommended to avoid meltymelty)
2. Plug up a network cable to your AntMiner S3. Plug the other end of the cable up to your LAN or directly to your PC (if your local network is set up on a different subnet - see below)
2a. If your local network is not running on 192.168.1.0 with a subnet mask of 255.255.255.0, use the direct cable connection method and set your wired interface IP to a static IP (such as 192.168.1.1 subnet mask 255.255.255.0, no gateway).
2b. If your local network is running on 192.168.1.0 with a subnet mask of 255.255.255.0, ensure no devices are already using 192.168.1.99 (use ping 192.168.1.99 to check) and plug the AntMiner S3 directly up to a free port on your switch or router.
3. Connect to your AntMiner S3 by going to your web browser and typing http://192.168.1.99/ (username is root, password is also root)
4. Configure your miner settings under the Miner Configuration tab, then save and apply the settings.
5. Go to the Network tab. Select "Edit" on the WAN line.
6. Change protocol from "Static Address" to DHCP client. Set an appropriate hostname (such as antMiner) then click Save and Apply.
You will now lose access to the device. If you had it connected to your network, check your router to find out what IP it now has. If you had it connected directly to your PC (from having a different subnet, such as 192.168.0.0), disconnect it now and connect it to your local network instead, then do as above to find its new IP.
7. Log back in and confirm everything is working correctly. You should also feel a fair bit of warm air coming from the output end of the miner.
That is it!
Additional Steps:
Enabling Wireless - This will require some hardware modification and will probably void warranty, do so at your own risk!
The following is more technical than the previous instructions. It assumes you know how to connect devices to your wireless network, configure them, and how to safely drill holes in metal. If you have any doubts on how to do this, STOP NOW and ask someone who does know what they are doing.
Open the case of your AntMiner S3. Identify the controller board, mounted on the top of the inside of the unit (where the network port is). On this board is mounted a smaller board containing an AR9331 system on chip. Near the bottom left corner of this board (Labelled ThinkPHY 2) is a U.FL antenna connector. You will need a suitable pigtail and antenna (both can be sourced from ebay for about $1.50 each, some of the most common are the U.FL to RP-SMA ones, and antennas are easy to find).
Carefully drill a hole the correct width for the pigtail to be mounted (do this without the board in the way, and ensure no metal filings end up in bad places), mount the antenna end of the pigtail in the case, then carefully and gently fit the U.FL connector to the antenna connector on the board.
Reassemble the unit, then attach the antenna to the pigtail's now protruding wireless antenna socket.
1. Power up the unit (connected by wire to your LAN) and confirm everything is functioning normally through the web interface.
2. Go to the Network tab, then select the Wifi subtab.
3. Next to Generic MAC80211 802.11bgn (radio0), click the Add button.
4. On the new page displayed, set the ESSID to your wireless network name, the mode to client, and set the appropriate security settings under the Wireless Security subtab (about half way down the page, near where you set the ESSID). Set the network to "Create" and call it wifi.
5. Click Save and Apply. (And wait a while for everything to apply)
6. Select the Interfaces subtab, there should now be a third network option called WIFI (along with the two original ones, LAN and WAN). Click the edit button for WIFI.
7. Change the protocol from Unmanaged to DHCP client. Set an appropriate hostname, then click Save and Apply again.
8. Confirm the AntMiner S3 has successfully associated to the wireless network and acquired an IP. If it has not, confirm your security settings are correct and check the device Kernel Logs from the Status page.
9. Once correctly associated, you should now be able to access the miner through its wireless network IP. If this is possible, disconnect the wired network connection and confirm the unit keeps mining.
1. Plug up your power supplies to your AntMiner S3. Minimum of one PCI-e power connector per side (2 recommended to avoid meltymelty)
2. Plug up a network cable to your AntMiner S3. Plug the other end of the cable up to your LAN or directly to your PC (if your local network is set up on a different subnet - see below)
2a. If your local network is not running on 192.168.1.0 with a subnet mask of 255.255.255.0, use the direct cable connection method and set your wired interface IP to a static IP (such as 192.168.1.1 subnet mask 255.255.255.0, no gateway).
2b. If your local network is running on 192.168.1.0 with a subnet mask of 255.255.255.0, ensure no devices are already using 192.168.1.99 (use ping 192.168.1.99 to check) and plug the AntMiner S3 directly up to a free port on your switch or router.
3. Connect to your AntMiner S3 by going to your web browser and typing http://192.168.1.99/ (username is root, password is also root)
4. Configure your miner settings under the Miner Configuration tab, then save and apply the settings.
5. Go to the Network tab. Select "Edit" on the WAN line.
6. Change protocol from "Static Address" to DHCP client. Set an appropriate hostname (such as antMiner) then click Save and Apply.
You will now lose access to the device. If you had it connected to your network, check your router to find out what IP it now has. If you had it connected directly to your PC (from having a different subnet, such as 192.168.0.0), disconnect it now and connect it to your local network instead, then do as above to find its new IP.
7. Log back in and confirm everything is working correctly. You should also feel a fair bit of warm air coming from the output end of the miner.
That is it!
Additional Steps:
Enabling Wireless - This will require some hardware modification and will probably void warranty, do so at your own risk!
The following is more technical than the previous instructions. It assumes you know how to connect devices to your wireless network, configure them, and how to safely drill holes in metal. If you have any doubts on how to do this, STOP NOW and ask someone who does know what they are doing.
Open the case of your AntMiner S3. Identify the controller board, mounted on the top of the inside of the unit (where the network port is). On this board is mounted a smaller board containing an AR9331 system on chip. Near the bottom left corner of this board (Labelled ThinkPHY 2) is a U.FL antenna connector. You will need a suitable pigtail and antenna (both can be sourced from ebay for about $1.50 each, some of the most common are the U.FL to RP-SMA ones, and antennas are easy to find).
Carefully drill a hole the correct width for the pigtail to be mounted (do this without the board in the way, and ensure no metal filings end up in bad places), mount the antenna end of the pigtail in the case, then carefully and gently fit the U.FL connector to the antenna connector on the board.
Reassemble the unit, then attach the antenna to the pigtail's now protruding wireless antenna socket.
1. Power up the unit (connected by wire to your LAN) and confirm everything is functioning normally through the web interface.
2. Go to the Network tab, then select the Wifi subtab.
3. Next to Generic MAC80211 802.11bgn (radio0), click the Add button.
4. On the new page displayed, set the ESSID to your wireless network name, the mode to client, and set the appropriate security settings under the Wireless Security subtab (about half way down the page, near where you set the ESSID). Set the network to "Create" and call it wifi.
5. Click Save and Apply. (And wait a while for everything to apply)
6. Select the Interfaces subtab, there should now be a third network option called WIFI (along with the two original ones, LAN and WAN). Click the edit button for WIFI.
7. Change the protocol from Unmanaged to DHCP client. Set an appropriate hostname, then click Save and Apply again.
8. Confirm the AntMiner S3 has successfully associated to the wireless network and acquired an IP. If it has not, confirm your security settings are correct and check the device Kernel Logs from the Status page.
9. Once correctly associated, you should now be able to access the miner through its wireless network IP. If this is possible, disconnect the wired network connection and confirm the unit keeps mining.