I noticed there did not appear to be a default iptables configuration nor any firewall configuration applet (like Mint) on the PostmarketOS load...

So, as I haven't hand jammed policies in years, anyone have a recipe built to leverage iptables (which is installed, just doesn't have any rules configured) to protect the phone?  I haven't tested with my regular SIM card from my Android phone yet, just WiFi testing so far...but when I go on the vendor's network, that's more or less like being naked online without something to protect me. 

Not criticizing.  I know the devs are furiously working on the phone features as we post...just curious.

Why am I posting the following on this forum?



Because, apparently I cannot seem to get this issue resolved. I am not certain if the different departments of Pine64 actually communicate with each other when there is a problem or an issue, but it does not appear that they do from my perspective.



The last response I received from Pine64 Sales on 8/25/2020.



Dear Douglas Kitchen,



Both orders have been submitted and pending on 4PX response. We will resolve the undelivered packages as soon as 4PX response us.



Thank you and will keep in touch with you!



Regards,

Pine64 team





On 8/13/20 2:02 PM, Sales Pine 64 wrote:

Quote:Dear Douglas Kitchen,

Thank you for contacting us. We will contact 4PX service to follow up consignments of order 130041 and 130046 to deliver soon.

Have a nice day!

Regards,
Pine64 team

I just flashed the 9/06 dev release of the Manjaro KDE Mobile edition and my phone wouldn't even turn on. The red light came on and the screen light turned on for a moment then it went black. Anyone else have this issue? Also tried the Alpha7 version and got the same result with 2 different sd cards.

I know this was just released and is a work in progress, but I am wondering, if after a lot of work, could this be used as a basis for a watered down Medical Alert?
I define my ideal system as a wearable device with a button to mash, maybe wifi. The pinephone is powered up and always on (wall power), used as a base station. The alert signal from the bracelet or lanyard goes to the pinephone, activates an app, the app dials a predetermined number and sends a predetermined sms text message. "Jane Doe has activated her alert-system and want you to come check on her". It would have nothing to do with 9-11 and wouldn't need a monthly subscription fee (except for the phone service).
Seems like creating the wearable device is the real hurdle. (knowing a lot of software work is needed too)
Would the pinephone hardware be capable? And your thoughts about such a project at this time?

I've prepared a multi-boot image for people who want to easily try as many distributions as possible. Official website is now here: https://xnux.eu/p-boot-demo/




Video: https://www.youtube.com/watch?v=kyvFNGUxtIY

https://megous.com/dl/tmp/multi2.mp4

Or: https://www.youtube.com/watch?v=NqyuKysK6ag

https://megous.com/dl/tmp/multi4.mp4 or https://megous.com/dl/tmp/multi5.mp4



Some history/details are on my blog: https://xnux.eu/log/



You can reach me at p-boot@xnux.eu

Hi Everyone,

Just got my PinePhone with PostmarketOS last week.  Still working issues with it.  One of the issues is a rapidly pulsating buzzing-like sound from the speaker.  It started when I had the phone booted and pulled the charging cord out of it.  Immediately the pulsing sound started.  On reboot, the sound kicks in about the desktop is displayed.  The only thing that diminishes the volume is setting the Sound Output Configuration to "Play HiFi quality music" (is that setting usable for making calls?).  If the speaker output device is tested, the sound resumes at low volume for about 8 seconds then stops.  Any ideas on how to stop this from happening?

The version I'm running is 5.7.0 #3-postmarketos-allwinner

Thanks

I wanted easy access to the serial port and a power button that I could use without a tool, so I made a few additions to my RockPro64 and NAS case.

https://imgur.com/a/Exahmhk

As discussed here, the board has two through-hole pads that are connected to the on-board power button's leads. Shorting them to each other is equivalent to pressing the button. They're just the right size for a pin header, so I soldered one in.



I then wired a matching jumper to a panel-mount button, which fit nicely through the case's IR sensor hole.



Here it is from the outside:



I wired another jumper from the serial console pins on the board's GPIO header to a 3.5mm female TRS connector (aka stereo headphone jack). It fit between the hard drive cage and the case panel, and just barely fit through one of the three semicircular case holes that come with rubber plugs. I covered it with heat shrink tubing as a precaution against shorts.



Here it is from the outside:



Of course, I also wired a male connector to a jumper that fits my serial/USB adapter:



I followed the wiring that FTDI uses on their 3.5mm serial adapters, so those should be compatible with my NAS.

From the board's point of view:

Connector Tip: RXD / RockPro64 pin 10
Connector Ring: TXD / RockPro64 pin 8
Connector Sleeve: GND / RockPro64 pin 6

This makes accessing the serial console pretty convenient. I can even use a standard 3.5mm stereo extension cable if I need a longer reach.

Parts list:

• CW Industries GPB081A09R pushbutton switch, panel mount, M5 threads
  
• CUI Devices SJ1-3513 3.5mm right-angle stereo jack, M6 threads
  
• Adafruit 1800 3.5mm stereo plug
  
• Adafruit 3141 ribbon cable with female/female jumper connectors
  
• Adafruit 3145 jumper housings
  
• TE Connectivity 5-146281-2 single-row 2-pin header, 2.54mm pin pitch
  
• Heat shrink tubing that I already had
  

Be aware, these tests are being executed using an out-of-box testing methodology. All tests are preformed with minimal interaction/setup of devices outside of: OS imaging/updating,  SIM installation, Wifi Configuration,  and Power Cycling the devices.

Results: mobian/09-08-2020-TMobile.html


               mobian/09-08-2020-Verizon.html

Conclusion: OS is not Ready for pinephone to be daily driver.


Notes: The Microphone is still really sensitive. The audio out quality is suffering. Camera still super laggy. I've notice that the apps are taking longer to load. The Camera and Firefox are taking 15 seconds+ to load. I ran another longevity test, When the phone goes to sleep it disconnects from wifi and cell data. Texts are no longer getting through when this happens.

Because I find the "need" to flash new OS images to SD cards and the eMMC of the phone, there is an equal need to backup these images. I think that we would all like to save ourselves the trouble of reconfiguring from scratch if it can be avoided. I've found some Windows desktop applications to accomplish this task, and each has its strengths and weaknesses. Connect SD card directly to PC or use Jumpdrive for eMMC. I will continue to update with new tools as necessary.

After some testing, I have to recommend Win32DiskImager as the best overall product for backups, assuming you have the storage space for it.

Win32DiskImager

• Best overall product. Simple UI with fastest transfer speeds.
  
• Strength: Saves images in standard .img format.
  
• Weakness: Direct copy results in images being the same size as the drive, which in this case is 30 times as large as Aomei.
  
• Note: The partitions will be listed as separate drives, but it will read and save the entire drive if you pick one of them. I pick the first one to be safe.
  
• Bonus: Balena Etcher can fail when writing to eMMC from a Windows PC and using Win32DiskImager resolves this issue.
  

• Best for systems with limited storage.
  
• Strength: Intelligent sector copy only saves info for blocks that have data written to them and also features compression. Mobian on a 64GB sd card takes up less than 2GB as an image.
  
• Weakness: Saves images in proprietary .adi format and need paid option for functionality
  

• Best for people afraid of CLIs. It's a slower Win32DiskImager with a prettier UI and some extra features.
  

Be aware, these tests are being executed using an out-of-box testing methodology. All tests are preformed with minimal interaction/setup of devices outside of: OS imaging/updating, SIM installation, Wifi Configuration, and Power Cycling the devices.

Results: ubports/2020-09-08-TMobile

Conclusion: This OS is not ready for the device to become a daily driver.

Notes: Still open to the idea that the camera button is to reverse the image not switch to the 'selfie camera' if anyone can confirm either way I would appreciate it. Failed 4G outbound call still an issue; the failed call no longer kills audio on all other calls. Other issues still persist. Boot time was good. Still an issue with lock mode.

Issues:
Unable to send 3G SMS Since Dev-158
4G outbound calls broken.
Phone gets stuck in a weird lock state when spamming power button.