Just a quick note, not entirely on-topic:
Bill Paul wrote:
[...]
>Yes, I know there's a minimum frame length of 60 bytes. And the rl_encap()
>routine has the following code:
> /* Pad frames to at least 60 bytes. */
> if (m_head->m_pkthdr.len < RL_MIN_FRAMELEN) {
> m_head->m_pkthdr.len +=
> (RL_MIN_FRAMELEN - m_head->m_pkthdr.len);
> m_head->m_len = m_head->m_pkthdr.len;
> }
[...]
>60 bytes, I just adjust bump up m_pkthdr.len and m_len. This adjuster
>length gets used later in rl_start() when transmission is triggered.
I haven't read through the code yet, so I don't know where the extra
memory in that buffer originated from, or rather if it has been zeroed
before reaching this point. Otherwise you are leaking data from the
kernel out to the network.
Other OSes have done this before. It can be used for "data fishing"
by just pinging the machine. Eventually it turns up all sorts of
interesting information ([partial] passwords, for example).
How many other NICs are unable to auto-pad, and how many of the
drivers just add "random" data that happened to be laying around
inside the kernel...?
Just curious,
/Mikko
(Off to make sure that if_ed in my home firewall isn't doing
anything like this...)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
