Re: Blocking "shodan.io" - What are my options?

[Radek]

> A little ncat, sed, pfctl, and a dash of cron are able to do 
> the job just fine.  cron is just there to start the ncat processes at 
> boot and run an hourly script to do a pfctl -T expire  86400 to 
> keep the table clean of old attackers.
Sounds good. Could you share your script here?

On Thu, 3 Jan 2019 15:20:44 -0800
Misc User  wrote:

> On 1/3/2019 3:06 PM, Jordan Geoghegan wrote:
> > Hello,
> > 
> > I wrote a small script called 'pf-badhost' to block shodan and other 
> > annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html 
> > to see the script.
> > 
> > pf-badhost also blocks ssh bruteforcers and other annoyances by loading 
> > a list of regularly updated badhost lists from trusted sources. If you 
> > only want to block shodan specifically, just comment out the few lines 
> > that download the other blocklists, and you should be good to go. I've 
> > had a number of people give good feedback on it, and they've reported it 
> > blocking the scanners and baddies quite effectively; BSDNow also did a 
> > piece about it, so it seems to work alright.
> > 
> > 
> > Cheers,
> > 
> > Jordan
> > 
> > 
> > On 01/02/19 22:15, Antonino Sidoti wrote:
> >> Hi,
> >>
> >> I wish to block all attempts by "shodan.io". Basically I run an 
> >> OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of 
> >> traffic all stemming from "shodan.io". I have PF configured so I was 
> >> wondering how to block such a domain from making any attempts to 
> >> connect to my server. There is little information about Public IP 
> >> addresses being used by "shodan.io" scanner, so making an IP list for 
> >> PF may be futile.
> >>
> >> Could someone suggest a possible option? I was thinking along the 
> >> lines of "relayd" or "squid proxy". My server is hosted at Vultr and 
> >> has a single WAN interface with Public IP. There is no internal LAN 
> >> interface.
> >>
> >> For those who do not know about "shodan.io", please do a search and 
> >> you will discover what it does.
> >>
> >> Regards
> >>
> >> Nino
> >>
> > 
> 
> 
> I've always been a fan of just setting up a simple script to open a 
> couple ports with ncat, then when a client connects to the port, it gets 
> shoved into pf table that has a `drop' rule attached to it.  No messing 
> about with blocklists or proxies or anything else.
> 
> ncat listens on various low-number ports that nothing is using on my 
> servers.  A little ncat, sed, pfctl, and a dash of cron are able to do 
> the job just fine.  cron is just there to start the ncat processes at 
> boot and run an hourly script to do a pfctl -T expire  86400 to 
> keep the table clean of old attackers.
> 
> Shodan isn't the only scanner out there, so there is no point in just 
> blocking it.  And I figure if someone is trying to connect to unused 
> ports on my system, they probably aren't up to any good.  If you aren't 
> aware that my machine isn't legitimately listening on 22 or 23, or 443, 
> I don't want to talk to you.
> 
> I usually just run on port 22 and move sshd to a different port, that 
> seems to stop >95% of attackers.
> 
> 


-- 
radek

Request for testing

[Otto Moerbeek]

Hi,

If you ever thought about getting more involved and learning a bit
about buikdling a current OpenBSD, there's a call for testing at

https://marc.info/?l=openbsd-tech=154521488707434=2

Testing would provide me with valuable data about performance of
memory management in multi-threaded applications.

Thanks,

-Otto

Re: Blocking "shodan.io" - What are my options?

[Antonino Sidoti]

Hi Jordan,

Sincere thanks for sharing your script. Also thanks to others for their input 
and comments.

Regards

Nino

> On 4 Jan 2019, at 10:19 am, Jordan Geoghegan  wrote:
> 
> Sorry for the double post, I got the link to the script wrong... woops.
> 
> The actual link is:
> 
> www.geoghegan.ca/pfbadhost.html
> 
> 
> On 01/03/19 15:06, Jordan Geoghegan wrote:
>> Hello,
>> 
>> I wrote a small script called 'pf-badhost' to block shodan and other 
>> annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html to 
>> see the script.
>> 
>> pf-badhost also blocks ssh bruteforcers and other annoyances by loading a 
>> list of regularly updated badhost lists from trusted sources. If you only 
>> want to block shodan specifically, just comment out the few lines that 
>> download the other blocklists, and you should be good to go. I've had a 
>> number of people give good feedback on it, and they've reported it blocking 
>> the scanners and baddies quite effectively; BSDNow also did a piece about 
>> it, so it seems to work alright.
>> 
>> 
>> Cheers,
>> 
>> Jordan
>> 
>> 
>> On 01/02/19 22:15, Antonino Sidoti wrote:
>>> Hi,
>>> 
>>> I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD 
>>> (6.4) mail server using OpenSMTPD and notice quite bit of traffic all 
>>> stemming from “shodan.io". I have PF configured so I was wondering how to 
>>> block such a domain from making any attempts to connect to my server. There 
>>> is little information about Public IP addresses being used by "shodan.io" 
>>> scanner, so making an IP list for PF may be futile.
>>> 
>>> Could someone suggest a possible option? I was thinking along the lines of 
>>> “relayd” or "squid proxy”. My server is hosted at Vultr and has a single 
>>> WAN interface with Public IP. There is no internal LAN interface.
>>> 
>>> For those who do not know about “shodan.io”, please do a search and you 
>>> will discover what it does.
>>> 
>>> Regards
>>> 
>>> Nino
>>> 
>> 
> 

Re: Blocking "shodan.io" - What are my options?

[Misc User]

On 1/3/2019 3:06 PM, Jordan Geoghegan wrote:

Hello,

I wrote a small script called 'pf-badhost' to block shodan and other 
annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html 
to see the script.


pf-badhost also blocks ssh bruteforcers and other annoyances by loading 
a list of regularly updated badhost lists from trusted sources. If you 
only want to block shodan specifically, just comment out the few lines 
that download the other blocklists, and you should be good to go. I've 
had a number of people give good feedback on it, and they've reported it 
blocking the scanners and baddies quite effectively; BSDNow also did a 
piece about it, so it seems to work alright.



Cheers,

Jordan


On 01/02/19 22:15, Antonino Sidoti wrote:

Hi,

I wish to block all attempts by “shodan.io”. Basically I run an 
OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of 
traffic all stemming from “shodan.io". I have PF configured so I was 
wondering how to block such a domain from making any attempts to 
connect to my server. There is little information about Public IP 
addresses being used by "shodan.io" scanner, so making an IP list for 
PF may be futile.


Could someone suggest a possible option? I was thinking along the 
lines of “relayd” or "squid proxy”. My server is hosted at Vultr and 
has a single WAN interface with Public IP. There is no internal LAN 
interface.


For those who do not know about “shodan.io”, please do a search and 
you will discover what it does.


Regards

Nino






I've always been a fan of just setting up a simple script to open a 
couple ports with ncat, then when a client connects to the port, it gets 
shoved into pf table that has a `drop' rule attached to it.  No messing 
about with blocklists or proxies or anything else.


ncat listens on various low-number ports that nothing is using on my 
servers.  A little ncat, sed, pfctl, and a dash of cron are able to do 
the job just fine.  cron is just there to start the ncat processes at 
boot and run an hourly script to do a pfctl -T expire  86400 to 
keep the table clean of old attackers.


Shodan isn't the only scanner out there, so there is no point in just 
blocking it.  And I figure if someone is trying to connect to unused 
ports on my system, they probably aren't up to any good.  If you aren't 
aware that my machine isn't legitimately listening on 22 or 23, or 443, 
I don't want to talk to you.


I usually just run on port 22 and move sshd to a different port, that 
seems to stop >95% of attackers.

Re: Blocking "shodan.io" - What are my options?

[Jordan Geoghegan]

Sorry for the double post, I got the link to the script wrong... woops.

The actual link is:

www.geoghegan.ca/pfbadhost.html


On 01/03/19 15:06, Jordan Geoghegan wrote:

Hello,

I wrote a small script called 'pf-badhost' to block shodan and other 
annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html 
to see the script.


pf-badhost also blocks ssh bruteforcers and other annoyances by 
loading a list of regularly updated badhost lists from trusted 
sources. If you only want to block shodan specifically, just comment 
out the few lines that download the other blocklists, and you should 
be good to go. I've had a number of people give good feedback on it, 
and they've reported it blocking the scanners and baddies quite 
effectively; BSDNow also did a piece about it, so it seems to work 
alright.



Cheers,

Jordan


On 01/02/19 22:15, Antonino Sidoti wrote:

Hi,

I wish to block all attempts by “shodan.io”. Basically I run an 
OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of 
traffic all stemming from “shodan.io". I have PF configured so I was 
wondering how to block such a domain from making any attempts to 
connect to my server. There is little information about Public IP 
addresses being used by "shodan.io" scanner, so making an IP list for 
PF may be futile.


Could someone suggest a possible option? I was thinking along the 
lines of “relayd” or "squid proxy”. My server is hosted at Vultr and 
has a single WAN interface with Public IP. There is no internal LAN 
interface.


For those who do not know about “shodan.io”, please do a search and 
you will discover what it does.


Regards

Nino

Re: Blocking "shodan.io" - What are my options?

[Jordan Geoghegan]

Hello,

I wrote a small script called 'pf-badhost' to block shodan and other 
annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html 
to see the script.


pf-badhost also blocks ssh bruteforcers and other annoyances by loading 
a list of regularly updated badhost lists from trusted sources. If you 
only want to block shodan specifically, just comment out the few lines 
that download the other blocklists, and you should be good to go. I've 
had a number of people give good feedback on it, and they've reported it 
blocking the scanners and baddies quite effectively; BSDNow also did a 
piece about it, so it seems to work alright.



Cheers,

Jordan


On 01/02/19 22:15, Antonino Sidoti wrote:

Hi,

I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) mail server 
using OpenSMTPD and notice quite bit of traffic all stemming from “shodan.io". I have PF 
configured so I was wondering how to block such a domain from making any attempts to connect 
to my server. There is little information about Public IP addresses being used by 
"shodan.io" scanner, so making an IP list for PF may be futile.

Could someone suggest a possible option? I was thinking along the lines of “relayd” 
or "squid proxy”. My server is hosted at Vultr and has a single WAN interface 
with Public IP. There is no internal LAN interface.

For those who do not know about “shodan.io”, please do a search and you will 
discover what it does.

Regards

Nino

Re: USB stick recovery after dd with miniroot64.fs

[Hiltjo Posthuma]

On Thu, Jan 03, 2019 at 06:19:41PM +0200, Mihai Popescu wrote:
> Hello,
> 
> I used a storage USB stick to dd the miniroot64.fs on it. It was the
> wrong one with some useful files saved on it and I did the dd
> if=miniroot64.fs of=/dev/rsd1c bs=1m and let it write. The USB size is
> almost 32Gb, it was configured as one msdos partition, sd1i.
> 
> Is there any chance to recover even some files from this USB stick?
> I read some disaster recipes, but I want to ask for the best one, to
> avoid even more damage.
> 
> Thank you.
> 

sysutils/testdisk is very good.

Good luck,

-- 
Kind regards,
Hiltjo

Re: Blocking "shodan.io" - What are my options?

[Peter Müller]

Hello Nino,

well, there is a list of known Shodan scanners available:
https://wiki.ipfire.org/configuration/firewall/blockshodan

However, it seems to be outdated - I observed "dojo.census.shodan.io"
(IPv4: 80.82.77.139), too.

Since scanners usually try to bypass blocking attempts or
rate limits, I doubt maintaining an IP list makes sense.
Querying RBLs or lists of known networks hosting malware
(i.e. Spamhaus DROP) probably requires less manual effort.

Thanks, and best regards,
Peter Müller


> Hi,
> 
> I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) 
> mail server using OpenSMTPD and notice quite bit of traffic all stemming from 
> “shodan.io". I have PF configured so I was wondering how to block such a 
> domain from making any attempts to connect to my server. There is little 
> information about Public IP addresses being used by "shodan.io" scanner, so 
> making an IP list for PF may be futile.
> 
> Could someone suggest a possible option? I was thinking along the lines of 
> “relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN 
> interface with Public IP. There is no internal LAN interface.
> 
> For those who do not know about “shodan.io”, please do a search and you will 
> discover what it does.
> 
> Regards
> 
> Nino
> 


-- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
-- bugtraq

Re: Who is 'anchor 11' (pfctl -vvss ./. pfctl -vsA)?

[Philipp Buehler]

Am 02.01.2019 21:35 schrieb Klemens Nanni:

Anchor 11 is the twelfth rule in your main ruleset (the anchor rule),
in which the first rule established this state.


Ouch, overlooked this one. Thanks..


Provide your ruleset so we can look at actual rules without guessing in
case your problem persists, `pfctl -a\* -s rules' prints them including
anchors.


Hmm, still a bit ambigious:
===
@11 anchor "relayd/*" all {
  [ Evaluations: 21256227  Packets: 845613Bytes: 363090876   States: 
31]

  [ Inserted: uid 0 pid 12958 State Creations: 16822 ]
anchor "depa_portal_http" all {
}
anchor "depa_portal_https" all {
}
anchor "rnexus_portal_http" all {
@0 pass in quick on rdomain 0 inet proto tcp from any to public-ip port 
= 80 flags S/SA keep state (tcp.established 600) tag RNEXUS_PORTAL_HTTP 
rdr-to  port 60280 round-robin sticky-address
  [ Evaluations: 8919094   Packets: 1101  Bytes: 56088   States: 
0 ]

  [ Inserted: uid 89 pid 29940 State Creations: 162   ]
}
anchor "rnexus_portal_https" all {
@0 pass in quick on rdomain 0 inet proto tcp from any to public-ip port 
= 443 flags S/SA keep state (tcp.established 600) tag 
RNEXUS_PORTAL_HTTPS rdr-to  port 60643 
round-robin sticky-address
  [ Evaluations: 13343728  Packets: 253   Bytes: 57853   States: 
0 ]

  [ Inserted: uid 89 pid 29940 State Creations: 18]
}
anchor "ssfn-imaps" all {
@0 pass in quick on rdomain 0 inet proto tcp from any to public-ip port 
= 993 flags S/SA keep state (tcp.established 600) tag SSFN_IMAPS rdr-to 
 port 993 round-robin sticky-address
  [ Evaluations: 169032000  Packets: 4965436   Bytes: 1932456130  
States: 22]

  [ Inserted: uid 89 pid 29940 State Creations: 33036 ]
}

So, for every redirect one anchor (as expected/designed) - and each has 
a rule 0.
Besides from the ip/port tuple (the state in question was to port 993), 
I cannot follow this down

to which relayd-subanchor?

ciao
--
pb

install mirrors weirdness

[Mihai Popescu]

Hi,

I am interested in some bigger ports, like Gigs of download, so I
tried some mirrors from my country. The download rate is superb, but I
found some weird things and I don't know how to explain them.

1. https://mirrors.nav.ro/pub/OpenBSD/snapshots/packages/amd64/
gtk+3-cups-3.24.2.tgz package is missing, but it can be found on other mirrors.

2. https://mirrors.pidginhost.com/pub/OpenBSD/snapshots/packages/amd64/
libreoffice-6.1.1.2p0v0.tgz
libreoffice-6.1.1.2p1v0.tgz
libreoffice-6.1.1.2p2v0.tgz
libreoffice-6.1.4.2v0.tgz
there are 4 packages listed, not found this on other mirrors.

I have no idea about tools used to do mirroring or checking, but is
this ok for a mirror?
As a reference and day by day install i use ftp.hostserver.de

Thanks.

Re: USB stick recovery after dd with miniroot64.fs

[Janne Johansson]

Den tors 3 jan. 2019 kl 17:21 skrev Mihai Popescu :
> I used a storage USB stick to dd the miniroot64.fs on it. It was the
> wrong one with some useful files saved on it and I did the dd
> if=miniroot64.fs of=/dev/rsd1c bs=1m and let it write. The USB size is
> almost 32Gb, it was configured as one msdos partition, sd1i.
>
> Is there any chance to recover even some files from this USB stick?
> I read some disaster recipes, but I want to ask for the best one, to
> avoid even more damage.


http://ports.su/sysutils/ddrescue
or
http://ports.su/sysutils/testdisk

perhaps?


-- 
May the most significant bit of your life be positive.

USB stick recovery after dd with miniroot64.fs

[Mihai Popescu]

Hello,

I used a storage USB stick to dd the miniroot64.fs on it. It was the
wrong one with some useful files saved on it and I did the dd
if=miniroot64.fs of=/dev/rsd1c bs=1m and let it write. The USB size is
almost 32Gb, it was configured as one msdos partition, sd1i.

Is there any chance to recover even some files from this USB stick?
I read some disaster recipes, but I want to ask for the best one, to
avoid even more damage.

Thank you.

Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

[Tom Smyth]

Hello All,

im just updating a legacy thread on Proxmox KVM Hosts for OpenBSD Guuests
The KVM / Proxmox 5.x  Preemption timer in Linux Kernel In proxmox 5.3 ...
OpenBSD 6.4 Guests work fine without any modifications to the
Proxmox System, (ie you no lonter need to disable the)
/sys/module/kvm_intel/parameters/preemption_timer

so OpenBSD Runs fine on an unmodified Proxmox 5.3 Box ...
so the KVM / Linux Bug that caused OpenBSD guests to Freeze  seems
to be resolved in Proxmox  5.3 ...  (so users of 5.0 , 5.1 may want to
upgrade
to the latest version of Proxmox

I hope this helps
Tom Smyth


On Mon, 15 Jan 2018 at 21:34, Tom Smyth 
wrote:

> Hello all, I just want to reference the following post which resolved
> my issues of running
> OpenBSD guests on Proxmox 5.x
>
> Just to clarify  Todds / Stefans Email in another thread  (Thanks
> Stefan and Todd,)
>
> https://marc.info/?l=openbsd-misc=151600765414976=2
>
>
> disable kvm_intel.preemption_timer on the host (see \
> > /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be
> buggy in linux \
> > 4.10 and newer
>
> disabling intel-kvm preemption_timer worked for me and it resolved the
> timer drift issue
> in openbsd on Proxmox 5.1
>
> so in debian / proxmox  I ran the following command
>
> echo options kvm-intel preemption_timer=N >>/etc/modprobe.d/kvm-intel.conf
> Thanks,
>
> Tom Smyth
>
> On 30 December 2017 at 23:25, Tom Smyth 
> wrote:
> > Hello I have repeated OpenBSD 6.2  Testng on Proxmox PVE
> > 5.1 3r Relasee CD
> >
> > The console does not hang like in previous releases of Proxmox
> > PVE 5.x
> > However the issue of  delays between pings (slow sleep time) stil
> > is there since the 5.1 Release 2 and is present in 5.1 release 3 iso
> > (the Proxmox 5.1 CD that was released 22 December 2017
> >
> > if I do date;sleep 1;date
> > I will get the first time and date, and the second time about
> > 9-11 seconds after the first...  and the interval between pings is
> > sporadic... I will raise a case with Proxmox again about this
> > Ill do some further digging...
> > Thanks
> >
> > On 27 October 2017 at 07:18, Tom Smyth 
> wrote:
> >> Hello Theo, Mike, All,
> >>
> >> @Theo Understood it is important to protect developers and the project
> goals
> >> ... @Mike Thanks for your Generosity in the time you took on this
> thread,
> >> Yes I want Mike to make VMM more awesome :)  @Mike keep up the good work
> >>
> >> I cant disagree with any point that Theo made in his email on this tread
> >> that said,
> >> unfortunately I cant always choose my hypervisor and I dearly want to
> run
> >> OpenBSD on it proxmox...
> >>
> >> I do think (based on the fact that OpenBSD 6.0-6.2 works on PVE 4.4 it
> is
> >> probably a (virtual Hardware issue ) .. not necessarily an OpenBSD issue
> >> I will raise this with the PVE Support guys (as I have already done
> since mid
> >> July )
> >>
> >> Any further posts on this thread from me will be (hopefully for other
> OpenBSD
> >>  users benefit (if I make progress)
> >> and certainly not intended as a request or a distraction for Core
> >> OpenBSD Developers
> >>
> >> All the Best,
> >>
> >> Tom Smyth
> >>
> >> On 27 October 2017 at 06:37, Theo de Raadt  wrote:
> >>> Tom,
> >>>
> >>> A virtual machine setup is an operating system running on an operating
> >>> system on top of an operating system.
> >>>
> >>> OK, not quite.  The middle one, the VM itself, is as a bit less
> >>> complex than a full operating system as machine-independent code goes,
> >>> but nevertheless the machine-dependent bat-shit-crazy stuff is far
> >>> more complex with gobs of extremely messy nuances face it on both
> >>> sides because x86 is a fucking minefield
> >>>
> >>> Everyone needs to adjust their expectation that all 3 layers are
> >>> perfect, AND not assume that it is our layer doing the wrong thing
> >>>
> >>> Really the layers should simplify but the current marketplace is still
> >>> gaining more value out of product differentiation than
> >>> simplification+convergence, both sw and hw
> >>>
> >>> Even if our subsystem isn't doing something 'right', it is NOT the
> >>> stated goal of OpenBSD to run well on every garbage VM, because it has
> >>> become impossible for the little guy to be perfect.
> >>>
> >>> Concerted efforts to diagnose and improve these low-level issues uses
> >>> the same crowd of people who are trying to improve other edges which
> >>> may be more important.  do you want our vmm to work well?  or do you
> >>> want us to work better on someone else's vmm?  Sorry, limited
> >>> skillset, pick what you want mlarkin to focus on!  But that is unfair,
> >>> and even if he listened to your wishlist, UNPRODUCTIVE.
> >>>
> >>> Where does this go?  Get ready for monopolies in everything, or
> >>> oligopolies at best... or fight their establishment.
> >>>
>  Just to say the gaps in ping response seems  get worse as the uptime
> increases
>  ie
>  with the uptime around 5 minutes the gaps between ping 

Re: Are there real mountpoints for gvfs/gio shares ?

[Antoine Jacoutot]

On Thu, Jan 03, 2019 at 02:22:53PM +0100, Joel Carnat wrote:
> Hi,
> 
> I was looking at mounting CIFS shares.
> OpenBSD is the "client" machine.
> CIFS a published by a remote NAS.
> 
> Using XFCE and Thunar, everything works well.
> But when I try to access the mountpoints from the console, I just can't find
> them.
> 
> Things like "gio mount smb://", "gio mount -l" and "gio copy" work well.
> 
> I read there should be stuff in ~/.gvfs or /run/user/ on Linux.
> But couldn't find anything mounted on such directories on OpenBSD.
> 
> Is there a way to access the gvfs shares using regular console tools (other
> than gio) ?

Hi.

I doesn't work on OpenBSD because it requires fuse(4) and the ability for
regular users to mount a filesystem which is a privileged operation.

-- 
Antoine

Are there real mountpoints for gvfs/gio shares ?

[Joel Carnat]

Hi,

I was looking at mounting CIFS shares.
OpenBSD is the "client" machine.
CIFS a published by a remote NAS.

Using XFCE and Thunar, everything works well.
But when I try to access the mountpoints from the console, I just can't 
find them.


Things like "gio mount smb://", "gio mount -l" and "gio copy" work well.

I read there should be stuff in ~/.gvfs or /run/user/ on Linux.
But couldn't find anything mounted on such directories on OpenBSD.

Is there a way to access the gvfs shares using regular console tools 
(other than gio) ?


Thanks.

Re: OPenBSD 4.9 i386, Asus EEE 701, no network

[Marco Bonetti]

Hi there,
I've one of those machines running some ancient version of  OpenBSD and I can
confirm the wired interface works.
For the wireless one, instead, try -current as other people already pointed out
or buy a cheap Intel wifi card and swap it out (I did this).

--
Marco Bonetti

Re: mount_ffs Permission denied as root

[Marcus MERIGHI]

Hello, 

myml...@gmx.com (myml...@gmx.com), 2019.01.03 (Thu) 01:21 (CET):
> On 1/1/19 10:02 PM, Philip Guenther wrote:
> > On Tue, Jan 1, 2019 at 6:27 PM myml...@gmx.com 
> > mailto:myml...@gmx.com>> wrote:

[snip]

> I unmounted the drive and tried to create an image of the drive, but it
> fails
> 
> 20190102-1435:root@curry:/root:#time dd if=/dev/rsd2c of=/root/corsair.iso
> bs=1k
> dd: /dev/rsd2c: Input/output error
> 15958016+0 records in
> 15958016+0 records out
> 16341008384 bytes transferred in 7313.789 secs (2234274 bytes/sec)
>   122m03.94s real 0m16.54s user 6m36.66s system

To make dd(1) continue after such errors read up on these operands:

conv=noerror(,sync)

Marcus

Re: OPenBSD 4.9 i386, Asus EEE 701, no network

[Peter N. M. Hansteen]

On Tue, Jan 01, 2019 at 05:13:47AM -0700, oletus wrote:
> Having this exact same issue with EeePC 701 and OpenBSD 5.9. It uses the
> lii0 driver. So far no luck with DHCP.
> 
> dmesg says about the driver,
> lii0 at pci2 dev 0 function 0 "Attansic Technology L2" rev 0xa0 apic 1 int
> 17, address 00:1f:c6:d5:3c:80

As others have already pointed out, this is the wired ethernet interface. 

I vaguely remember at least some of the Eee models came with wifi built in. 

Looking at the wikipedia page https://en.wikipedia.org/wiki/Asus_Eee_PC I would 
guess that ath(4) or possibly one of the several Ralink drivers (ral(4), 
rum(4), 
run(4)) might be appropriate, *if* your unit has wifi (some came only with 3g 
connectivity it seems).

That said, it's probably more useful to try with a supported version, meaning
at this point OpenBSD 6.4 or 6.3, and if you find that your unit does not have
wifi onboard, you could probably find a cheap USB wifi thing that recent OpenBSD
versions support.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.