"Failed to bring up br0"

[ghost]

Failed to bring up br0, other than that everything is looking good. Any suggestions?

[wismna]

Sorry for late reply!
Do you have any more details on the error? Did you make sure you have the bridge-utils package installed?

[ghost]

No other errors that I can remember. I'll have to check when I get home about that and if I have the bridge utility installed.

One more thing, while I have you, do you know anything about getting the whole backdoor part of this working. I've looked everywhere and can't seem to get and even clue as to how it all works. I'm afraid that if anything it's only left me more confused. So if you have any insight or maybe could throw out a little step by step I would be most sincerely greatful.

[ghost]

^as would many others..from what I've seen many people are having much trouble with getting the backdoors to funtion.

[wismna]

Ok, let me know. Though I'm wondering, are you saying that while there is an error bringing up br0, HackPi still seems to be working? E.g, when connected to a computer, it is detected and starts PoisonTap?

As for the backdoor, unfortunately, I don't quite know how it works either, sorry... But I'll be digging around to get a better understanding one of these days.

[whoot]

Having the same issue!
Followed your installation instructions and after reboot the pi says:

interface usb0 does not exist!
interface usb1 does not exist!
Waiting for br0 to get ready
RTNETLINK answers: File exists
Failed to bring up br0

EDIT:
So there are two issues that might solve the problem.

1. isc-dhcp-server location is wrong. Correct is

sudo mv -f ~/HackPi/isc-dhcp-server /etc/default/

2. On boot the raspberry says:

[ERROR] failed to load Kernel Modules

This may be because the USB dwc2 is currently 4.4.48+ and not 4.4.38+ and therefore overwriting the file will cause the error.

[wismna]

Ah! You're right, I will correct the default path.
Also, concerning the kernel module, it is indeed built against the 4.38+ kernel and not the 4.48+. I will rebuild it for this version an upload it.

[whoot]

Thanks a lot!
Im writing a installer atm and will make a pull request once im finished

[wismna]

Very nice installer, thanks!
I built and uploaded the new kernel module (4.4.48+), and slightly modified your installer to reflect the changes I made to the project structure, as well as kernel version detection.
Let me know if everything works and especially if br0 is going up successfuly.

[whoot]

sure thing!
However, we need to enhance the kernel check, because if there is a new version, then the installer will fail.

[wismna]

Indeed. We could add a check to abort installation if the kernel version is different from the ones that exist.
It should also be possible to script the kernel module building. I already added a new readme file explaining the steps required to make one.

[whoot]

I will try to implement this check.
I have tested the new module and the "Failed to bring up br0" error still exists.
However Win 10 recognizes the Pi as a network interface, and i can access it via SSH. Yay :)

[wismna]

It's possible that this error occurs at startup, when the dummy ethernet gadget is created for fingerprinting purposes. br0 can't start at this point (it's normal). Then, when the real gadget is created, br0 can start (and apparently does, otherwise I think you wouldn't be able to connect to it and Windows wouldn't recognize it).
I'll try preventing it from auto starting in interfaces (as it's manually started after gadget creation anyways), see how it goes.

[whoot]

Could you please explain why the bridge interface is needed in first place?

[wismna]

I explained it in the readme file (agreed, it's a bit long!) :).
Basically, each libcomposite function (the ECM function for Linux and MacOs and the RNDIS function for Windows) creates an usbX interface. I didn't want to duplicate iptables, routes etc. rules nor change server configurations to listen on several interfaces, so I implemented the bridge interface as the main interface.

Also, because of an update, MacOs is not longer smart enough to ignore the RNDIS function (which needs to be declared first for Windows) and load the ECM function as it used to (and Linux still does). So, the ECM function needs to be declared first, and that means there will only be one usb interface that could be brought up: usb0. Everything that would be bound to the usb1 interface would fail.

Finally, it is somehow future-proof: if at some point I decide to add a new function (EEM?), I will only need to add it to the list of interfaces bound by the bridge and not worry about other configurations.

[whoot]

Sorry, but i still dont get why the second interface (usb1) is needed and why it is not possible to just use usb0.

I'll try preventing it from auto starting in interfaces (as it's manually started after gadget creation anyways)

You mean this?:

/etc/network/interface

post-up route add -net 0.0.0.0/0
post-up iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 1337

/etc/rc.local

/sbin/route add -net 0.0.0.0/0 br0
[...]
/sbin/iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 1337

[wismna]

No, I simply meant this:

/etc/network/interface

auto lo br0

However, the duplicates lines you've quoted are something I need to clean up. They shouldn't be needed in /etc/network/interface but if I remove them, it didn't seem to be working anymore...

About the bridge, it's not that you can't use usb0... I'll try to explain better.
For Windows to work, I had to create a specific function, RNDIS in gadget.sh. This one has to be declared first so it will listen on usb0.
Then, I create the ECM function for Linux and Mac. As it's created second, it will come up on usb1.
Since they both exist at the same time, there are two interfaces, usb0 and usb1.

But at this point, HackPi actually doesn't know which interface the host will use, because it doesn't know what kind of host it's connected to (except for MacOs thanks to fingerprinting, but that is another story). Windows will connect to the usb0 interface, but Linux will skip that one and connect to the usb1 interface. That means the servers and network configuration had to be set up on usb1 too, otherwise HackPi wasn't working during my tests.
This is why I thought of using a bridge. Hope I managed to be a bit clearer!

[whoot]

Ah, now I get it. Thanks for the explanation.
Too bad fingerprinting doesnt work on Windows/Linux. However, nice workaround with the bridge though.

[wismna]

You're welcome.
Actually, it should be possible to make it work for any OS. That would require some dedication and more advanced USB traffic analysis, however. See this link.
At some point, I'd like to find time to implement this...

[whoot]

At this point i think the error message has to do something with the duplicated lines / auto start of the interfaces.
I still get the error message at boot, however I can login locally with "raspberrypi.local" and when i run brctl show i get the following:

> brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.426164555342       no                 usb0
                                                           usb1

And ifconfig shows:

br0       Link encap:Ethernet  HWaddr 42:61:64:55:53:42
          inet addr:1.0.0.1  Bcast:255.255.255.255  Mask:0.0.0.0
          inet6 addr: fe80::c47e:3fff:feb3:96c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:619 errors:0 dropped:0 overruns:0 frame:0
          TX packets:744 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:81248 (79.3 KiB)  TX bytes:55697 (54.3 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:324 errors:0 dropped:0 overruns:0 frame:0
          TX packets:324 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:26244 (25.6 KiB)  TX bytes:26244 (25.6 KiB)

usb0      Link encap:Ethernet  HWaddr 42:61:64:55:53:42
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:623 errors:0 dropped:4 overruns:0 frame:0
          TX packets:697 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:81424 (79.5 KiB)  TX bytes:78422 (76.5 KiB)

usb1      Link encap:Ethernet  HWaddr 42:61:64:55:53:43
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[wismna]

Yeah probably. However, each time I changed anything to these lines, it would stop working altogether... I'm looking into it.
Also, during my testing, I wasn't getting any error message about the bridge. Are these showing in dmesg?

From what I can see of brctl show and ifconfig output, it does indeed seem to be correctly working (well, that, and also the fact that you can SSH into it!)

[whoot]

Yeah probably. However, each time I changed anything to these lines, it would stop working altogether

This is exactly what happens to me.

I'm looking into it.

Any news?

[wismna]

No news for now, I've been busy on other projects. But I'll get back to it probably this week.

[PrettyBoyPBM]

Hi, in the code you say sudo chmod +x installer.sh but give the error no such file etc :c i should change for install.sh?

[whoot]

Hey,

where in the code? The "install.sh" states:

Usage:
chmod +x install.sh
./install.sh

[PrettyBoyPBM]

Thanks u! everything works in my raspberry pi zero!. it's there a tutorial for the end server 🤔

[wismna]

Nice to hear! I updated the Readme.

[whoot]

Alright!
I tested everything on a clean Raspbian installation with Firmware version 4.9.
Installer works great, patching works great, device recognition under Win 10 works great, error is still there, but PoisonTap works IF there is no proxy defined in the browser.

However, i cant access HTTPS sites anymore with HackPi attached :(
The more I try to fix stuff, the more I think this whole PoisonTap thingy is more like a buggy proof of concept :/

[wismna]

Yeah, seems like it...
I'll probably start working on another project now that I can successfully create Ethernet gadgets, I have some ideas in mind.