apt-get update not working for Kali Wi-Fi bridge

[0phoi5]

Hi all,

I have created a Wi-Fi bridge using these instructions, using an RPi3's internal Wi-Fi (wlan0) and bridging to ethernet (eth0).

It works a treat, I can connect to my RPi hotspot and use the internet fine. I can ping all websites fine.

However, I cannot use apt-get update or install on the RPi being used as a bridge any more. It states;

root@RPi:~# apt-get update
Ign:1 http://http.kali.org/kali kali-rolling InRelease
Err:2 http://http.kali.org/kali kali-rolling Release
  Unable to connect to http.kali.org:http:
Reading package lists... Done
E: The repository 'http://http.kali.org/kali kali-rolling Release' does no longer have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

sources.list contents are;

deb http://http.kali.org/kali kali-rolling main non-free contrib
deb-src http://http.kali.org/kali kali-rolling main non-free contrib

I also cannot ping http.kali.org, it fails.

Pinging yahoo, google or facebook from the RPi bridge works fine.

How can I continue to use apt-get update and install on this RPi, whilst keeping it as a bridged Wi-Fi hotspot?

Thank you.

Edited January 22, 2017 by haze1434

[barry99705]

It shouldn't matter, but add 8.8.8.8 to the rpi's DNS.  Also what happens if you do a traceroute to Kali.org?

[digip]

As Barry mentioned, make sure it's not a DNS issue. a Traceroute to http.kali.org as well as changing to Google's DNS 8.8.8.8 or even OpenDNS should help clear that up first.

Can you do a  uname -a and tell us what version you're running though? Then also cat /etc/apt/sources.list  again, make sure it's set to:

deb http://http.kali.org/kali kali-rolling main contrib non-free
# For source package access, uncomment the following line
# deb-src http://http.kali.org/kali kali-rolling main contrib non-free

The above sources repo, is for latest kali branch(2016.1). If you're on an older kali kernel version that wants sana source files, you need the older sources and the above wont(shouldn't) work and could even break the install. Make sure your not on the older sana release, and are actually on kali-rolling if using latest version of kali sources. Otherwise, I'd suggest downloading the latest iso and starting over. I don't own any arm devices, so I can't test for you, but have a look on the Kali forums for the same error messages, sure if someone has had the same issue, it will def be posted there somewhere with the workaround if it's a legit but or such.

As for not finding http.kali.org, this will redirect you to the closest mirror. I personally had to blacklist in my hosts file one of the mirrors due to similar issues. You will see the name of the mirror though in the screen once it tries to do the update, so not sure you're getting that far yet. Slow downloads or frozen updates will show the mirror name in the update though and you can blacklist them, then restart your download and it will look for the next mirror and go through, but I don't see that in your above output.

[0phoi5]

47 minutes ago, barry99705 said:

It shouldn't matter, but add 8.8.8.8 to the rpi's DNS.  Also what happens if you do a traceroute to Kali.org?

Neither traceroute nor tracert appear to be recognised, I might not have traceroute installed;

root@RPi:~# traceroute kali.org
-bash: traceroute: command not found
root@RPi:~# tracert kali.org
-bash: tracert: command not found

Amending the last line in /etc/resolv.conf from nameserver 192.168.1.254 to 8.8.8.8 and rebooting the RPi results in the following when running apt-get update;

root@RPi:~# apt-get update
Err:1 http://http.kali.org/kali kali-rolling InRelease
  Temporary failure resolving 'http.kali.org'
Reading package lists... Done
W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease  Temporary failure resolving 'http.kali.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.

 

Edited January 22, 2017 by haze1434

[0phoi5]

7 minutes ago, digip said:

Can you do a  uname -a and tell us what version you're running though?

Linux RPi 4.1.19-v7 #1 SMP Tue Mar 15 15:10:00 CDT 2016 armv7l GNU/Linux

I will try amending my sources.list now.

Edited January 22, 2017 by haze1434

[0phoi5]

Sources.list was;

deb http://http.kali.org/kali kali-rolling main non-free contrib
deb-src http://http.kali.org/kali kali-rolling main non-free contrib

I have amended to;

deb http://http.kali.org/kali kali-rolling main contrib non-free
# For source package access, uncomment the following line
# deb-src http://http.kali.org/kali kali-rolling main contrib non-free

apt-get update then states;

root@RPi:~# apt-get update
Ign:1 http://http.kali.org/kali kali-rolling InRelease
Err:2 http://http.kali.org/kali kali-rolling Release
  Unable to connect to http.kali.org:http:
Reading package lists... Done
E: The repository 'http://http.kali.org/kali kali-rolling Release' does no longer have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

 

[digip]

When did you download and install it? I could be wrong, but your version looks to be older. ARM might not be as current as x86 side on updates though. As far as I know, the latest is form July across all versions though. Updating might not be possible this way either and you should try a fresh download and install(hopefully have a spare sd card or can backup important files) and try again.

 

Also, check your DNS. You can edit /etc/resolv.conf to change from your ISP or DHCP settings's DNS to eother google's orOpenDNS, and try again, but I have a feeling it's not a current release you're using.

 

Can you also run "cat /etc/*ele*" and post the output?

Here is mine for comparison:

Here are the latest ARM images: https://www.offensive-security.com/kali-linux-arm-images/ Scroll down for your corresponding Raspberry version

Edited January 22, 2017 by digip

[0phoi5]

49 minutes ago, digip said:

Can you also run "cat /etc/*ele*" and post the output?

Thanks. I installed 3 days ago, did apt-get update and apt-get dist-upgrade successfully around 2 days ago, before I followed the instructions here to create the bridge, after which apt-get fails.

Looks to be the same;

DISTRIB_ID=Kali
DISTRIB_RELEASE=kali-rolling
DISTRIB_CODENAME=kali-rolling
DISTRIB_DESCRIPTION="Kali GNU/Linux Rolling"
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2016.2"
VERSION_ID="2016.2"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.kali.org/"
SUPPORT_URL="http://forums.kali.org/"
BUG_REPORT_URL="http://bugs.kali.org/"

 

Edited January 22, 2017 by haze1434

[digip]

So it is 2016.2 and the sources are set correctly for this version, so that wont be an issue. Only thing I can think is DNS as originally suggested, or it's being blocked somewhere, either by ISP's DNS or your LAN somewhere.

 

Try a ping to 192.99.200.113 which is one of the http.kali.org servers. If it comes back alive, you can try putting in your hosts file an entry for this like so:

127.0.0.1	localhost
127.0.1.1	kali
192.99.200.113	http.kali.org

This should be last resort fix, as the IP may change in the future. If the hosts file fix doesn't work, then we need to look into your systems DNS may be fouled up, although that should prevent internet and pinging other things like you did. Tools like dig and nslookup should also fail if it's your Pi's DNS that is broken, which again points back to Barry's post, changing the DNS servers to rule them out.

[0phoi5]

Thank you.

I am currently starting from scratch to be on the safe-side, duplicating the hostapd config files before amending them (which I should have done the first time).

As it's a home server/access point, it's not a major issue if I have to temporarily take the RPi access point down to run apt-get update/upgrade once a week, I may end up just doing this.

I will let you know if I have any luck.

Edited January 26, 2017 by haze1434

[0phoi5]

Unfortunately I've not had any luck yet.

As it stands, it's been quick and easy for me to simply create a script to stop hostapd, swap the /etc/network/interfaces and /etc/init.d/hostapd files out for the originals, and then reboot.

This then boots the Pi with IP 192.168.1.60 instead of 192.168.1.11 (as per the hostapd settings), which then allows me to use apt-get successfully.

I then just reverse the above and bring hostapd back up.

Takes a couple of minutes once a week, so probably not going to bother investigating this further! I'll let you know if I come across a fix.

[digip]

I ran into similar issues recently after some kali updates. I moved from Gnome to KDE and also noticed all the new systemd additions for services broke some of my scripts i use. I ended up doing the following in a script for starting my own side, since systemd is a bitch now. Put this in a shell script and then run it, see what happens. something like, netfix.sh

systemctl stop network-manager.service
systemctl start smbd.service
dhclient eth0
ping -c 3 google.com

then invoke with "bash netfix.sh" (doesn't have to be set to executable this way)  and see if at the end it can ping google. I also have in mine the echoing of name servers to /etc/resolv.conf after the dhclient part, and assignign static IP's to my nics (I have more than one setup on the VM) but should get them from dhcp lookup. I just like to hardcode my name servers and set static addresses for things so I can always log into the machine and monitor things when I do CTF's, many of my reverse shells are pre-scripted to use a static IP on the machine. You can make /etc/resolv.conf read only after adding them too so system doens't overwrite them, as I've had that issue in past cause my DNS to stop working. I really don't like network manager or systemd and prefer to set things up manually. (only need the smbd.service, if you use SAMBA for anything. Otherwise, not really need if you don't need netbios info or connecting to shares)

 

Another thing I've seen that helps, flushing adapters and deleting dhcp.leases as they sometimes store and don't update properly. You can also make a static entry in your router so your machine always takes the same IP and doesn't ty reusing the dhcp.leases file to grab an address already in use, which will also cause issues.

Edited February 3, 2017 by digip