Could it be that your IPTV is using a non-IP protocoll, e.g. an ethertype which
is not IPv4 nor IPv6, but something different? Like Powerline, G.hn or so? --
And which is blocked by pf?There are several protocol and type fields on the
different layers (MAC, IP, TCP/UDP), and I recently noticed
Am 22.09.2016 um 04:47 schrieb Philip Guenther:
> Backing up to the beginning...
>
> On Wed, Sep 21, 2016 at 2:39 PM, Peer Janssen <p...@pjk.de> wrote:
>> I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release
>> recently via bsd.rd install kernel.
>>
Am 29.09.2016 um 14:05 schrieb Stuart Henderson:
> On 2016-09-28, Peer Janssen <p...@pjk.de> wrote:
>> # tftpd -d /tftpboot
>>
>> tftpd: 192.168.0.81: read request for 'pxeboot'
>> tftpd: 192.168.0.81: read request for 'pxeboot'
>> tftpd: 192.168.0.
their
comparative working or failing cases!
Peer
Am 02.10.2016 um 17:54 schrieb Peer Janssen:
> Goal: Upgrade a working soekris net4801 from OpenBSD 4.6 to 6.0.
>
> First I copied the complete 256 MB SiliconDrive CF-Disk to a newer
> SanDisk 8 GB Ultra one and rebootet, which worked smoot
Am 02.10.2016 um 21:24 schrieb Paul Suh:
>> On Oct 2, 2016, at 3:06 PM, Peer Janssen <p...@pjk.de> wrote:
>>
>> Now I reinstalled on another CF-Disk (4GB Transcend) with another method
>> (miniboot.fs), this went through and first-rebooted just fine.
>>
>
alting directly after
logging in.
Peer
Am 02.10.2016 um 17:54 schrieb Peer Janssen:
> Goal: Upgrade a working soekris net4801 from OpenBSD 4.6 to 6.0.
>
> First I copied the complete 256 MB SiliconDrive CF-Disk to a newer
> SanDisk 8 GB Ultra one and rebootet, which worked smoothly and
g kernel is indeed the unaltered one from the other
i386 OpenBSD 6.0 machine, and these
https://marc.info/?l=openbsd-misc=144242763106881=2 hints were taken
into account.
Is a system like the soekris net4801 not supported any more? Or is there
something I can do to install the new version on it?
Peer
--
Peer Janssen - p...@pjk.de
Am 28.09.2016 um 13:27 schrieb Solène Rapenne:
> Le 2016-09-28 12:45, Peer Janssen a écrit :
>> TFTP pxeboot requests:
>>
>> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ
>> "pxeboot"
>> : 4500 0034 0002 1411 24ea c0a8 00
Am 28.09.2016 um 11:33 schrieb Peer Janssen:
> the request seems to be constructed in different ways. This goes
> beyond what tftpd man page says about tftpd's options. Indeed, it
> looks like there aren't any tftpd options for this kind of variation
> at all, so it seems to me
Am 28.09.2016 um 11:05 schrieb Peer Janssen:
> Am 28.09.2016 um 10:50 schrieb Solène Rapenne:
>> Le 2016-09-28 10:21, Peer Janssen a écrit :
>>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
>>> connected to an alix.3x box serving dhcp an
Am 28.09.2016 um 10:50 schrieb Solène Rapenne:
> Le 2016-09-28 10:21, Peer Janssen a écrit :
>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
>> connected to an alix.3x box serving dhcp and tftp.
>> alix.3x (Server):
>>
>> # tftp localhost
dhcpd.conf was indeed "pxeboot":
tftpd: 192.168.0.81: read request for 'pxeboo'
which strangly persisted some while even across killing and restarting
of dhcpd and powercycling the target.
Which might be a hint to some tftpd uninitialized buffer problem (or so).
Peer
--
Peer Janssen - p...@pjk.de
y std.9600" unknown off
tty02 "/usr/libexec/getty std.9600" unknown off
tty03 "/usr/libexec/getty std.9600" unknown off
tty04 "/usr/libexec/getty std.9600" unknown off
I also tried console:
# cu -d -l console -s 9600
Connected to /dev/console (speed 9600)
Seems configured at least -- but no data arrives. So still something is
missing.
Maybe some BIOS quirk, who knows.
Maybe someone on this list had a similar problem?
This is a very fresh install, I didn't update but reinstall completely.
Peer
--
Peer Janssen - p...@pjk.de
logger software
(instead of getty) directly to tty00 (once I know how to configure it),
so that when the box boots, it automatically starts logging, and if the
process disappears, it restarts it. Right?
Peer
--
Peer Janssen - p...@pjk.de
at the serial line. I
tried all of these (the were in 0 t o5):
# cu -d -l ttyC -s
9600
Connected to /dev/ttyC (speed 9600)
Result: no data at all arrives. I don't see what went wrong.
Peer
# dmesg
OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch
it, and how it works, to the user. This seems
bad to me.
Peer
and discover more of it.
Thanks for working so hard! I took a look at the libReSSL comments ...
hilarious !
Peer
, and we also need to support
each other, whatever happens. We are just one humanity. Some allow
themselves to look down to others, but this is never justified; they can
never know for sure that they wouldn't have done worse if they had been
in the other one's life and situation.
Take care
Peer
list is unreliable or
untimely, I'd think it's useless, and with it that mailing list.
Regards
Peer
Si ce message ne s'affiche pas correctement, vous pouvez le visualiser en
suivant ce lien.
entete
OPTIMISEZ VOS APPELS ENTRANTS !
100% de vos appels traitis (` partir de 39 ⬠HT)
Riservez votre numiro 0811, 0820, 0825
dhs ` prisent en cliquant ici !
bloc3
bloc4
bloc5
Conformiment `
20 matches
Mail list logo