Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: xuraax on March 04, 2022, 10:59:49 AM
-
Hi,
I have been trying to connect a Model B pi using a Mediatek dongle based on the MT7601u chip.
I based my setup on information from this https://climberg.de/post/tiny_linux_for_raspberry_pi since I could not find complete details on this forum. Unfortunately this did not work but after installing a couple of other tcz extensions I have managed to get to the stage were sudo wifi.sh comes up with a list of possible networks to connect to but when I duly inserting the correct wireless key the software is unable to confirm the connection.
I am communicating with the board via a headless connection through eth0 to the same modem.
Regards
xuraax
-
Hi, xuraax. For that dongle to work you need to load two extensions: wireless-KERNEL.tcz and firmware-mediatek.tcz (the first contains the necessary driver, the second contains the necessary firmware). wifi.sh should work after that.
If you'd like to try an alternative to wifi.sh, feel free to try my autowifi script, which is available here: https://gitlab.com/GNUser/autowifi
Note that to use the script you need to load two additional extensions: iw.tcz and eiwd.tcz
-
Have seeing this before and when it was some ssid password with some bad special characters.
Check your wifi.db file if it contains the correct ssid and password.
-
Hi @GNUser
Hi, xuraax. For that dongle to work you need to load two extensions:
Don't think so because @xuraax says:
- wifi.sh comes up with a list of possible networks to connect to
-
I confirm what @patrikg said above.
wifi.sh is recognising 6 networks in the vicinity. Also dmesg |grep mt7601u responds with:
[ 28.116089] usbcore: registered new interface driver mt7601u.
Where does wifi.db reside?
-
Hi xuraax
I believe wifi.db is in your home directory (/home/tc/wifi.db).
-
I am afraid it is not.
the find command did not find it either.
By the way the password just consists of uppercase characters and numbers. Also same issue when i tried to connect to another network with similarly simple password.
-
You could create the file yourself.
Create a file /home/tc/wifi.db which has the following line in it with the 3 fields tab separated:
Wifi_SSID Wifi_Password WPABack it up with:
filetool.sh -bTry to run this command that will take the first line of wifi.db and try to connect with that ssid and password.
sudo wifi.sh -a
-
@patrikg,
Thank you for your help.
Unfortunately still no success since ifconfig did not report any connection to wlan0.
However iwconfig reported this:
tc@box:~$ iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Does this mean anything to any of you?
Incidentally when I ran: sudo wifi.sh -a
the program tried to connect directly to the SSID in the file wifi.db so I guess that is not the issue.
Regards
-
Hello F,
Oh .............massive semiconductor corp MEdiaTek.
...........perhaps , the doctrines of such enterprises are "abstraction"of
Hardware abstraction Layers" of requiring specific information access
of drivers only "they" supply .........This could allow global devices to interface
with other semiconductor brands and devices...
Hynix.......and others dominate memory semiconductors.........
The big "A" have their own Hardware semiconductor silicon...........so their angle is
implicit to their corp
.........global PC platforms and MSOFT and main board hardware........that's "Bootstrap Legals" for who's hardware can interface to the IBM architecture PC hardware "through" the platform (MSOFT) offer............. that is a legal licensing that the buyer of hardware and their OS signs up to when they interact,
Regards
C
-
Hi,
I have finally managed to get my RPI to confirm a wifi connection with the modem. Here is what I did:
I went back to the original procedure outlined in the website I showed in my first post but instead of doing this:
network={
ssid="<ssid>"
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
psk=<psk>
}
I altered the above to include this:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
country=<Insert 2 letter ISO 3166-1 country code here>
update_config=1
network={
ssid="<Name of your wireless LAN>"
psk="<Password for your wireless LAN>"
}
Of course the proper country code, wireless name and password were duly inserted. At the same time wifi.db was retained.
I am not certain whether the above did the trick or it was just luck but after this, connection was achieved repeatedly.
I hope someone can explain.
Thanks and regards
-
That should be "GROUP=staff" or omitted, no?
-
I am afraid my previous update may give the wrong impression of why things worked. Here is why.
Following the successful connection with what, I had hoped, were the changes I made above I tried to replicate the setup for another wifi extender. This time round things did not work.
The first thing I noticed was that the changes I had hoped I had made in the previous post were not there. This is probably due me failing to carry out the proper backup to disk using the filetool.sh command. This is not the first time it has happened to me.
Any changes I tried including the suggestions by @Juanito failed to achieve a successfull connection. udhcpc kept reporting "reason = WRONG_KEY"
Finally it should be noted that reverting back the original contents to the files wifi.db and wpa_configure.conf re established to the connection to the original wifi extender effortlessly.
Thank and regards
-
hi xuraax,
I have a vague memory that normally wpa_supplicant.conf is recreated dynamically from wifi.db each time you boot piCore.
I don't believe country code is required in piCore.
Tiny Core/piCore is not your typical Linux distribution.
regards
Greg
-
@Greg,
You are correct the country code is not required in piCore. In fact all the 3 lines I inserted later outside this:
network={
ssid="<ssid>"
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
psk=<psk>
}are not needed at all. Also when I removed the file wifi.db and rebooted piCore still connected to the one wifi extender with which I had success. It seems reasonable to conclude that wifi.db is used solely in conjunction with wifi.sh.
I then experimented with connecting to 4 different wifi extenders in my possession altering only the above code. I had success with 2 but the other 2 continued to fail. I then investigated the internal setup of each extender and noted that each had a different "Security Mode" setup. The results were as follows:
Extender_1 WPA-PSK success
Extender_2 WPA+WPA2 PSK success
Extender_3 WPA2 Personal fail
Extender_4 WPA2 PSK fail
In Extender_3 I could change the Security Mode setup to "WPA Personal" after which the rpi connected successfully and repeatedly. Unfortunately in Extender_4 which also happens to be my newest and also the main Modem, you do not get any other security mode than WPA2 so still no joy. Again it seems reasonable to conclude that the differences between WPA and WPA2 are the reasons why I had problems connecting.
The question now comes down to how can one alter the code above to cater for this and why do most other hardware I have, don't have an issue adapting to Security Mode variations while piCore has?
Regards
-
Does using something like this help:
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP
group=CCMP
-
Pretty sure TKIP is not valid for WPA2. Newer devices probably have TKIP disabled altogether.
-
I tried proto=WPA2 either with TKIP in the other lines or CCMP (whatever they mean) as suggested by @Juanito but I still could not connect. I also tried to run the WPA_supplicant command with logging enabled but even though a lot of data gets recorded I could not make heads or tails of it.
Regards