Bridge mode - Internet OK, but no Admin access

I have (2) ITUS Shields.  Both have been updated to 1.51SP1.  One has had hotfix 16201 (the bridge hotfix) applied.

In both cases, in bridge mode, the Shield will pass Internet traffic after being plugged in for about 5-10 minutes.  However, it will not allow LAN access to the Shield appliance itself via HTTPS or SSH.  It is *not* leasing an IP address on my network, nor does it appear at x.x.x.111.

There's no point in having an inline IDS if I can't check the logs for alerts.

Strangely enough, Router mode works just fine and the device can be reached at 10.10.10.10, but the whole reason I bought the device was to use it in Bridge mode, as an inline IDS.

Is there some way to set the LAN IP of the device in Router mode so that it persists when I switch over to Bridge mode?  Or, is there any way to just use the device in router mode, as an inline IDS, without causing interference with my existing router (Ubiquiti ERL)?

Are there any bridge mode users here that have come up with a clever solution?  Or did it just work out of the box for you?

Do you have eth1 plugged into your LAN? In bridge, eth2 is unmanaged unlike in router.

Yes, I've followed the diagram from the Quick Start guide exactly, and double-checked that I wasn't using any console ports or making any silly mistakes.

Eth2 to router WAN
Eth1 to router LAN
Eth0 to modem

Hi Tonytiger

Were both you Shields working at one time and is they were when did they stop working? ie after hotfix or update?

roadrunnere42

They've never allowed LAN access in bridge mode.  I kept performing all the beta firmware updates in the YouTube videos in hope that it would be resolved.  Eventually, ITUS sent me another unit thinking that it had to do with hardware, but it appears to be software related since the replacement unit has the same problem.

Can someone explain the boot process in bridge mode, and how networking is configured?  The manual and device sticker says it should appear on my LAN at x.x.x.111 but since it does not, I'm wondering what it does to prepare?  Maybe something is failing?

I just toggled the hardware switch to bridge mode and plugged it in as the manual describes.  Is there something more I need to do to switch from router to bridge, software-wise?

In bridge mode you can access shield via https://x.x.x.111 or https://shield.lan but this asumes you're LAN is working well.
x.x.x will be based on the DHCP lease from your router.  


Your LAN (Wifi router?) needs to
1) have DHCP setup without overlap to x.x.x.111 x.x.x.112 - no other device can be assigned to this IP.
2) set the Shield ETH1 as gateway in the router - so x.x.x.111
3) optional (!) set a broadcast to x.x.x.255


On your router, do you see a DHCP lease for Shield? The MAC address will start with 2C:26 (AFAIK)
Can you ping from your computer x.x.x.111 and x.x.x.112 ?

What kind of router do you have? DDWRT routers have some issues (don't ask me why) but that's why the promiscuous mode is in the network settings.

Thanks for the reply!  I'll try another router tonight to see if I get any different results.

I'm using an Ubiquiti Edgerouter Lite PoE.

I've found my setup guide for bridge mode from the other forum:

---
Here's my bridge mode setup guide:

Prepare your own LAN / configure router:
1) LAN IP address: make sure it is not within the 192.168.1.110-120 range
2) DHCP IP pool range: make sure it is not overlapping the 192.168.1.110-120 range
3) DHCP Gateway: put here your router IP address
4) DHCP DNS server: 192.168.1.111 - this is the Shield ETH1 address.
5) DHCP DNS server - enable "Advertise router's IP in addition to user-specified DNS" to ensure web filtering works.

Now connect Shield into the LAN following the admin guides (link)
a) Shield ETH0 to the cable modem
b) Shield ETH2 to the router WAN port
c) Shield ETH1 to the router LAN port
d) Turn on Shield - wait 10 minutes for first time
e) Turn on Cable modem
f) Turn on Router

internet should be working now
Shield should be reachable on https://192.168.1.111/ or https://shield.lan

6) Logon to Shield using u/p admin/itus
7) Go to System > Administration and Change password
8) Go to Network > Interface and take note of the MAC address of BR-LAN


Thee router may assign another IP address to Shield.

To prevent this go back to the router web interface:
9) DHCP set static IP address for the BR-LAN MAC address to 192.168.1.111
---

Thanks to your post, I think I've discovered the problem.  First of all, the Shield doesn't obtain a DHCP lease from my Ubiquiti ERL.  I confirmed that this is the same case with 2 dd-wrt routers.  If I connect it to an old Belkin router though, sure enough, it ends up on .111

So I set a static IP on the Shield. However, the static IP settings so not persist after a power cycle of the Shield. And neither does the SSH dropbear instance setting, for that matter.  

I've confirmed this behavior on both of my Shield devices.

v1.51 SP1 is not usable like this.  There's no way i have time to fiddle with cables and static IP settings each time the Shield reboots.  I can't imagine there will be any updates to rectify these issues.

The hotfix posted by Hans addresses these issues and many more and is the recommended path: http://itus.accessinnov.com/Hotfix-160301-FINAL-td157.html

If you want to fix these two issues manually, go into System>Startup>Local startup and comment out the first few lines that say they can be safely removed. That's why the static IP doesn't persist between reboots. Then at the end add this right before the exit 0 :

sleep 30
/etc/init.d/dropbear restart

That will restore SSH access on reboot.

Fantastic.  The hotfix resolved these issues.

That said, there's one last thing that prevents me from putting this on my home network.  If there's a power failure (simulated by plugging everything into the same power bar and toggling the power switch), when the ITUS comes back online, it won't pass any Internet traffic until I power cycle the modem manually *afterwards*.  My existing Ubiquiti router has no issues recovering from a power event.  Is there going to be a fix for this?  Or is this unfortunately part of the design?

I spoke too soon.  The hotfix and all the rulesets get wiped out as soon as power is disconnected.  

Wow... No wonder why ITUS folded.

ITUS folded mainly due to hardware manufacturing issues, see the PCM
article.

When you do powercycle, do you get back to 1.51SP or to RC2? Since i
replace all backup images with 1.51 and the ubiots then this powercycle
issue did not happen anymore

not sure why this is the case, something in the stage1/2 loaders

These are the files that I have in the boot sector

-rwxr-xr-x    1 root     root      35862152 Nov 26 03:04 ItusbridgeImage
-rwxr-xr-x    1 root     root      58078856 Nov 26 03:02 ItusgatewayImage
-rwxr-xr-x    1 root     root      40859016 Nov 27 13:08 ItusrestoreImage
-rwxr-xr-x    1 root     root      58144392 Nov 26 03:01 ItusrouterImage
-rwxr-xr-x    1 root     root        470976 Mar 27  2015 octboot2.bin
-rwxr-xr-x    1 root     root       1138416 May 27  2015 u-boot-octeon_rhino_itus7x.bin

note the date and size of octboot and u-boot

to get this you need to go to CLI:

1) cd /tmp
2) mkdir save
3) mount /dev/mmcblk0p1 /tmp/save
4) cd /tmp/save
5) ls -al
6) umount /tmp/save

step 3 mounts the boot sector, this is normally also done by the upgrade script.
check at step 5 the file dates and sizes.

TODO - i will update the upgrade script to also update the stage 1/2 boot loaders.

When I powercycle, it reverts to 1.51 without the mention of the hotfix or date.  In addition, the ruleset which used to read March 11 rolled back almost a month.

I repeated the hotfix and ruleset updates, then powercycle to confirm that the first time wasn't just a fluke.

Your suggestion above about the stage 1/2 loaders; do I do this before or after the hotfix and ruleset upgrade?

When Shield is running, you are in stage 3. It sounds like you're not "saving" data porperly. AFAIK roadrunner42 dealt with this problem before.

Stage 1 is the boot loader
Stage 2 selects the boot script (router/bridge/gateway)

So if Shield is running, you can use my set of commands from CLI

Could he be running in the fail safe ramdisk mode?