Showing posts with label BB3. Show all posts
Showing posts with label BB3. Show all posts

Sunday, November 1, 2020

EA3500 OpenWRT WiFi to WiFi STA Routing

Setting up Cisco Linksys EA3500 as WiFi to WiFi (STA mode) to have wired ethernet clients instead of WiFi clients (as opposed to the typical AP mode). 

TL;DR; install OpenWRT; change Network - Interfaces IP address of EA3500; use wireless mode N, auto.

I want to connect my wired ethernet device, for example the Envox EEZ Bench Box 3 "Modular, open-source test & measurement chassis" to WiFi. Sounds simple enough...

Update: the above picture is not accurate unless router forwarding rules are manually applied.

In my prior blogs, I recorded some notes on setting up a Raspberry Pi as either a WiFi STA Router (not an AP!) to route local eth0 onto the wlan0 for WiFi-to-WiFi connection (most people do the reverse: hardwire a WiFi router to their ISP and use it as an access point routing wlan0 to eth0). The routed solution has the benefit of an arbitrary number of ethernet clients, but the disadvantage of being on a different network and requiring some manual routing configuration. An alternative solution used the clever wlan_kable app to instead bridge the local RPi eth0 onto the WiFi network. This is works much more gracefully with no manual routing config, but was limited to a single device. This was ok, as I only wanted by BenchBox3 to have WiFi network capability. However, I later experienced some oddities when downloading large automation scripts to the BB3. On to the next option: a "real" router.

I have an old Linksys EA3500 available. They can be found on ebay for around 10 bucks (cheaper than a Raspberry Pi!) Of course, the native firmware does not support using the WiFi radio as a client station. The first thing that comes to mind is WRT: either dd-wrt or OpenWRT. It seems that the dd-wrt solution will pretty much never happen, despite having support for a large number of routers. If it turns out you have one of those routers and want to use dd-wrt, be sure to read the Client Mode wiki.

The very first google search for OpenWRT EA3500 however, was a link to the OpenWRT firmware download page for the EA3500! Could it be that easy? Yes! I simply loaded the 19.07.04 Firmware OpenWRT Install and voila! OpenWRT on the EA3500!! 

This is not the first time I've used OpenWRT. See my prior blog on OpenWRT on EA3500 with RTL-SDR Stream.

If you don't know the password on the router, hold down the reset button for 30 seconds to factory reset (until the LED next to the power starts to blink). The default password is: admin

Upgrading from stock firmware is found under "Connectivity" (go figure).


Click on the "Choose file..." and select the OpenWRT file, and click "Start".


Note that if you are concerned about bricking your router, there are fallback options, and in particular I think the Tigard multi-protocol, multi-voltage tool for hardware hacking could be helpful for not only unbricking, but lots of other cool hardware hacking adventures.

For reference: OpenWRT also has an excellent EA3500 feature summary, copied here as we know things on the internet sometimes just vanish:

There's a wiki guide for OpenWRT: Connect to client Wi-Fi network. Alas I followed along multiple times and simply could not get my WiFi router to connect. Lesson #1: It won't tell you if you enter the wrong WiFi password for the AP you are trying to connect to as a STA client. It just won't work. (and will appear and disappear from the Network - Wireless "Associated Stations") Beyond that, the instructions were not completely clear for this router with various firewall settings, etc. Thus my notes are here:

As described at the beginning on the WRT wiki, if your local network is 192.168.1.x then the router interface needs to be changed to a different network, say 192.168.2.x; See Network - Interfaces:


Actually, I almost never leave a network default at 192.168.1.x as there will typically be a conflict such as this. Alas for this demo I was on a test network...

In my case, my PC was connected to the target wireless AP (referred to here as "your_SSID") and the EA3500 was plugged into my ethernet port. I disabled the WiFi on my PC that was on the same network (192.168.1.0) to configure the EA3500. After editing the IPv4 device address to some other network (e.g. 192.168.2.1), notice the defined network also changes. 


The wireless settings tab is also someplace that I was tripped up; Next, under Network - Wireless, click the scan button for Generic MAC80211 802.11bgn. (not the one ending in "an") Find your SSID and click the "Join Network" button and enter your SSID and pass phrase:. 


When saving, there will be a bit more config: leave mode set to "N" and change channel to "Auto".


Although previously pressing "save", it is not until you press the "Save & Apply" button:


That's it! Despite the wiki mentioning firewall settings, etc. It is not needed for basic functionality (you may still with to optimize and further secure the router). It is best to restart the BB3 and exit EEZ Studio as well before connecting with the new router.

Some other details:

Note the OpenWRT has SSH enabled by default:


See the luci essentials. Of particular interest are the /etc/config/uhttpd and /etc/config/luci configuration files for luci. See the other files in \etc\config for other config files:

Note that only 4 files are changed from the default install to get basic operational functionality:

/etc/config/dhcp
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv6 'server'
        option ra 'server'
        option ra_management '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

/etc/config/firewall

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan wan6 wwan'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'


(my /etc/firewall.user had nothing extra)

/etc/config/network

root@OpenWrt:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdb2:e9f2:64b4::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.1'

config interface 'wan'
        option ifname 'eth1.2'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth1.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'

config interface 'wwan'
        option proto 'dhcp'



/etc/config/wireless

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'mbus@f1000000/mbus@f1000000:pcie@82000000/pci0000:00/0000:00:01.0/0000:01:00.0'
        option htmode 'HT20'
        option channel 'auto'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'mbus@f1000000/mbus@f1000000:pcie@82000000/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT20'
        option disabled '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

config wifi-iface 'wifinet2'
        option ssid 'your_SSID'
        option device 'radio0'
        option mode 'sta'
        option key 'your_SSID_password_in_plain_text'
        option network 'wwan'
        option encryption 'psk2'


Of course, see that line: option mode 'sta' near the bottom of wireless settings: The key to all of this!


Sunday, October 25, 2020

Raspberry Pi Bridge eth0 to wlan0 with wlan_kabel

I spent a ridiculous amount of time trying to persuade native Raspberry Pi OS to bridge the local ethernet port onto the WiFi segment. (turns out it is apparently not possible) 

My intention is having a remote device such as my Envox BB3 programmable power supply with only a wired ethernet connection, connect to my WiFi segment so that I can use EEZ Studio without needing to plug the BB3 into a wired ethernet port. The connection is the same as before:



In my prior blog, I came up with a somewhat brute-force method of setting up a local DHCP server and using dnsmasq. However, as brute force methods go, it was also neither a very graceful nor flexible solution.

While surfing the internet looking for alternatives, there was one person that casually mentioned "you can also try wlan_kabel". This turned out to be a ridiculously cool solution!

Starting with my default headless Raspberry Pi setup, install git and clone escitalopram's wlan_kabel. You'll need the MAC address of the device to use; the BB3 shows this on the ethernet settings screen:




sudo apt-get install git
git clone https://github.com/escitalopram/wlan_kabel.git
cd wlan_kabel
make

# the magic (showing the example MAC address from the docs)
# you'll need to put your own address here:
sudo ./wlan_kabel wlan0 eth0 74:69:69:2d:30:11

That's it! It just works. There are of course limitations (one device connected to Raspberry Pi eth0 port).

To run wlan_kabel at boot time, put this in /etc/rc.local :
(/home/pi/wlan_kabel/wlan_kabel wlan0 eth0 74:69:69:2d:30:11 > /dev/null 2>&1) &
Don't forget to use your own MAC address, and be sure to include the training ampersand.

This is a vastly more graceful solution. Just plug in the RPi and connect to the IP address shown, in my case 192.168.1.114 then connect:


  Et voilĂ !


Note the hard-wired ethernet port of the BB3 on the other wise of the Raspberry Pi has an IP address from the WiFi.

Sunday, October 18, 2020

Envox EEZ Bench Box 3 Ground Modification - BB3 Safety Upgrade

Over the weekend, I received my EEZ Bench Box 3 that I backed on Crowd Supply. The assembly instructions are quite straightforward and easy to follow and I had it working fairly quickly:


Shortly after assembly however, I noticed the case was not properly grounded. I think this was on my mind, as my recent reflow oven retrofit had this exact same problem. And that's a commercial product by a much larger company!

I mentioned this over on the Envox Discord Channel;  I started the discord discussion on this topic in the #eez-bb3 channel, but it was suggested that I move it to the #crowdsupply channel. So the discussion continues there.

Sure enough: although there was an excellent paint job on the enclosure, there was not supposed to be paint where the standoffs meet the case:
"The fact is that one of the AUX-PS stand-off has connection to PE but enclosure maker didn't leave a part of bottom plate unpainted to make electrical contact" --prasimix (eez admin)
My initial solution was to scrape off the paint on the inside bevel of the screw holes. Done carefully, and there will be minimal to no visibility once the screws are re-inserted:


Note the screws are black (painted!) so for a good electrical contact, the undersides of the screws should *also* be scraped.  



Initially I used a hand-turned, over-sized drill bit to scratch off the paint in the holes:


Really on the back and bottom, I think plain silver, unpainted screws would be best, however I don't have any on hand. Even on the sides this might be a good idea, although admittedly the black screws on the nice blue case is quite aesthetically impressive. Still, safety should always take priority.

My next modification was to actually hardwire the ground connection to the case. Fortunately there's even a space lug awaiting the connector. Here the blue end is on the screw holding the power connecting to the case (also scraped off paint on case, see above) and the bare connector is attached to the extra lug on the auxiliary power supply:



Although my initial solution worked, it was admittedly lazy. The right way to do this would have been during assembly, to clean up all the paint around all of the standoffs. But I didn't really want to completely disassemble everything just to do this. 

I started with just the removal of the cover, and the side screws holding the auxiliary power supply:



I then scraped off the paint in a little perimeter around the holes to ensure the standoffs would make electrical contact:


The two holes closest to the rear of the unit (near the power cable) have standoffs that are in direct contact with the incoming earth ground on the power supply connector mounted on the PCB, so it would probably be a good idea to ensure these are in good contact with the case.



The red square to the left is the most important This one is closest to the inbound ground from the power connector (the ground pin in the small red square in the middle). Note the PCB trace. The connector to the right is not connected to anything.

I ended up removing all of the screws from the bottom case:


This allowed removing the bottom cover, without having to disassemble the entire front panel, display, PCBs, etc:


The paint is fairly durable, some sandpaper on the end of a pencil or small nut driver might work. I used a Dremel tool on lowest speed setting to gently clean off the paint around all of the standoff connectors in the bottom panel:


Note the two screws that connect the front panel two the base should also conduct. Pay extra attention to these to ensure the best contact. It is really quite surprising just how well the painted case acts as an insulator. But with quality paint, and even painted screws - that's exactly what happens. Even upon assembly, the screws do not scratch the paint enough to make an electrical connection.

Edit: it's really great when a lot of people participate! All sorts of great ideas come about. @timonsku has an excellent suggestion of using those toothed lock washers to help make contact!


When re-assembling, but sure to connect the wires FIRST, before moving everything into place. Otherwise it will be difficult to reattach them. (yes, I learned this the hard way and removed all the screws in the auxiliary power supply a second time)


Afterwards, simply replace the bottom plate.

Really what I need to do is order some longer screws, and connect the front panel to case ground with wires, and not rely only on the (painted) screws to make a good electrical contact. Note the screws holding the display plate are apparently built-in to the case (my unit arrived with the display already mounted, and the screws to not come through to the front panel). This would be an excellent place for a wired ground connection:


When reassembling, be sure to check to top lid as well. Mine is completely insulated from the power supplies (not good).


Really, I think this is the best suggestion: to have welded posts on all 4 case parts. Thanks [timonsku] :


Hopefully the EEZ folks will mention this early on in their assembly instructions, as this whole process would certainly be easier before the unit is assembled.

See also a discussion of the BB3 on eevblog and the eez-open releases, and firmware releases.


Find gojimmypi at gojimmypi.github.io

I'm currently working on my new blog home at  gojimmypi.github.io After implementing a variety of features such as dark mode , syntax hi...