On 21.03.2018 10:55, Matt Joras wrote:
> I'm going to be doing some stuff with raw sockets pretty soon, and
> while scrounging around, looking for some nice coding examples, I
> found the following very curious comment on one particular message
> board:
>
>
> https:
> On 21. Mar 2018, at 03:43, Eugene Grosbein wrote:
>
> On 21.03.2018 08:03, Michael Tuexen wrote:
>
>>> On 21. Mar 2018, at 00:39, Eugene Grosbein wrote:
>>>
>>> 21.03.2018 3:09, Ronald F. Guilmette wrote:
>>>
I'm going to be doing some stuff with raw sockets pretty soon, and
while
I am unable to send frames larger than 9216 bytes (destination MAC through
trailing CRC inclusive) using ixgbevf hardware with latest netmap code (LINUX).
What is the source of this limitation? From the chip datasheet it appears that
much larger frames are supported.
There is mention of 9216 i
This turned out to be a limitation of the box we are using, there is apparently
hardware between the ixgbevf chip and the fiber.
Joe Buehler
> I am unable to send frames larger than 9216 bytes (destination MAC through
> trailing CRC inclusive) using ixgbevf hardware with latest netmap code
> (
In message <5ab1a9c5.9050...@grosbein.net>,
Eugene Grosbein wrote:
>21.03.2018 3:09, Ronald F. Guilmette wrote:
>>
>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>> "Using raw sockets isn't hard but it's not entirely portable. For
>> instance,
In message <5ab23fb9.7050...@grosbein.net>,
Eugene Grosbein wrote:
>On 21.03.2018 10:55, Matt Joras wrote:
>> Saying "Not for FreeBSD" is needlessly confusing and not accurate. In
>> the common parlance "raw sockets" does not refer to libdnet, which is
>> not a part of the FreeBSD base system.
22.03.2018 0:38, Ronald F. Guilmette пишет:
>
> In message <5ab1a9c5.9050...@grosbein.net>,
> Eugene Grosbein wrote:
>
>> 21.03.2018 3:09, Ronald F. Guilmette wrote:
>>>
>>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>>> "Using raw sockets isn't har
22.03.2018 1:08, Ronald F. Guilmette wrote:
> OK, so, if I have understood all that has been said in this thread so
> far, then I would assert that, from the perspective of a simple-minded
> and naive end user (e.g. me), the assertion that I originally quoted
> -is- in fact correct, i.e. one -cann
In message <5ab2ad9f.6040...@grosbein.net>,
Eugene Grosbein wrote:
>Why should you concentrate on RAW sockets?
Well, for reasons that are completely legitimate, and that I'll
explain in detail, if anyone is seriously interested, I'd like
to check each IPv4 address within a set of about 90 or s
22.03.2018 3:03, Ronald F. Guilmette wrote:
>> Why should you concentrate on RAW sockets?
>
> Well, for reasons that are completely legitimate, and that I'll
> explain in detail, if anyone is seriously interested, I'd like
> to check each IPv4 address within a set of about 90 or so
> modest sized
I see. Unfortunately this breaks the API, so I don't think we can accept it.
We should probably sum up the fragment lengths, remember which one was the
first descriptor and write the olinfo field when we process the last
descriptor ...
I hope this does not slow down the simpler case where NS_MOREFR
In message <5ab2c0b1.3020...@grosbein.net>,
Eugene Grosbein wrote:
>It does not mean you need to stick with raw sockets API.
>libpcap can be used too, as I've shown in previous letter.
Thank you. If zmap ends up not suiting my needs, I will
definitely look into libpcap.
_
This problem has been preplexing me for ages and ages. I looked at it
again, just briefly, and re-read parts of some potentially relevant
RFCs, just the other day, but frankly, I'm just too ignorant and/or
too stupid to be able to think up a solution, so I'll just drop the
problem description her
22.03.2018 4:19, Ronald F. Guilmette wrote:
> This problem has been preplexing me for ages and ages. I looked at it
> again, just briefly, and re-read parts of some potentially relevant
> RFCs, just the other day, but frankly, I'm just too ignorant and/or
> too stupid to be able to think up a sol
Do you mean that the application banners for all applications are the
same? A comprehensive scan with nmap shows no differences?
I know you specified SSH as outside of the application layer, but I
would think if it's even to the point that the same SSH key (or
credentials) work for both machines,
>
> This problem has been preplexing me for ages and ages. I looked at it
> again, just briefly, and re-read parts of some potentially relevant
> RFCs, just the other day, but frankly, I'm just too ignorant and/or
> too stupid to be able to think up a solution, so I'll just drop the
> problem des
Thank you for bearing with me.
On 21.03.18 01:44, Rodney W. Grimes wrote:
...
Show me your full firewall rule set, without that I can only speculate
as to where it is getting blocked, but given your symptoms I highly
suspect the firewall is blocking the packets OUT of your SERVER back
towards
On Wed, 21 Mar 2018 14:19:43 -0700
"Ronald F. Guilmette" wrote:
>
> This problem has been preplexing me for ages and ages. I looked at it
> again, just briefly, and re-read parts of some potentially relevant
> RFCs, just the other day, but frankly, I'm just too ignorant and/or
> too stupid to b
In message <5ab2d11a.6060...@grosbein.net>,
Eugene Grosbein wrote:
>If they respond truly identically, there are no reasons to treat them like
>distinct hosts
>despite of different IP addresses.
Well, for my purposes, it would be inapporpriate to make any such leap
of faith.
If address A is s
"Kurt Buff" wrote:
>Do you mean that the application banners for all applications are the
>same? A comprehensive scan with nmap shows no differences?
Correct. This is the case I was/am asking about.
>I know you specified SSH as outside of the application layer, but I
>would think if it's eve
In message <201803212204.w2lm4g8h023...@pdx.rh.cn85.dnsmgr.net>,
"Rodney W. Grimes" wrote:
>One thing you could look at is the OS finger printing of nmap,
>that could look for possible things to diffentiate the hosts.
Yea, that idea occurred to me. But this solution has the same problem
that
> Thank you for bearing with me.
>
> On 21.03.18 01:44, Rodney W. Grimes wrote:
>
> ...
>
> > Show me your full firewall rule set, without that I can only speculate
> > as to where it is getting blocked, but given your symptoms I highly
> > suspect the firewall is blocking the packets OUT of you
On Wed, Mar 21, 2018 at 4:47 PM, Ronald F. Guilmette
wrote:
>
> "Kurt Buff" wrote:
> In case it was not clear, none of the IPv4 addresses that are of interest,
> or that are relevant to my question, are ones for which *I* posses any type
> of SSH login credentials.
>
> But your question certainly
> On Mar 21, 2018, at 4:47 PM, Ronald F. Guilmette
> wrote:
>
> But your question certainly raises an interesting possibility, and an
> interesting question... one that I myself am not at all equiped or
> qualified to answer (because I am almost totally ignorant about even
> the bare mechanics
>
> In message <201803212204.w2lm4g8h023...@pdx.rh.cn85.dnsmgr.net>,
> "Rodney W. Grimes" wrote:
>
> >One thing you could look at is the OS finger printing of nmap,
> >that could look for possible things to diffentiate the hosts.
>
> Yea, that idea occurred to me. But this solution has the sa
hi,
I'm updating my freebsd wifi bits in preparation for more work and ... well:
ath1: using multicast key search
random: harvesting attach, 8 bytes (4 bits) from ath1
.. ipfw
ipfw2 initialized, divert loadable, nat loadable, default to accept,
logging disabled
.. ipfw_nat
*** Setting kern.ra
On 22.03.2018 09:23, Adrian Chadd wrote:
> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode)
> [ thread pid 11 tid 100010 ]
> Stopped at 0
> db> bt
> Tracing pid 11 tid 100010 td 0x80673b40
> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144
> dyn_tick+0x238 (0,?,?,
27 matches
Mail list logo
