Yehonatan, good day.
Mon, Feb 25, 2008 at 11:28:12AM +0200, Yehonatan Yossef wrote:
> I'm a freebsd newbee, trying to port an ethernet driver from Linux to
> FreeBSD 6.3.
> I'm facing a system reboot upon loading of the driver, and I could use a
> tool for capturing dmesg upon system crash (such a
Mon, Feb 25, 2008 at 03:41:03PM +0200, Yehonatan Yossef wrote:
> I'm looking into the syslogd capabilities at the moment, it might be
> enough.
Syslog can die too early to spot everything. But your mileage may vary.
> I've tried following the serial console setup you've pointed, but when I
> add
Giulio, good day.
Thu, Mar 13, 2008 at 02:43:57PM +0100, Giulio Ferro wrote:
> Pyun YongHyeon wrote:
>> To rule out other possible issues, would you try the following
>> files on your box?
>>
>> http://people.freebsd.org/~yongari/re/if_re.c
>> http://people.freebsd.org/~yongari/re/if_rereg.h
>>
Stefan, good day.
Thu, Mar 20, 2008 at 03:43:44PM +0200, Stefan Lambrev wrote:
>>> But here is working example which you can improve off course.
>>>
>>> #dual home
>>> pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1
>>> keep state
>>> pass out on $ext_if2 route-to ($
Good day!
I've made two PRs (and pathes for them) that are related to the networking
subsystem.
URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=94408
Name: kern/94408: if_bridge breaks proxy ARP functionality
Description:
Proxy ARP entries will not be correctly processed if they belongs to t
> One problem which we are experiencing right now is that any user from
> private lan can use any ip address he wants. If he boots his computer with a
> stolen ip address, the poor owner of that machine(not active at the moment)
> will give automatically up his ip address to this user. The same
> To prevent users from MAC-spoofing - buy a switch with some kind of
> "port-security". If you could lock down a port to just one MAC and have a
> static ARP on the router it would be pretty hard to spoof the MAC-address.
> With
> another MAC than the one associated with the port you simply wi
> But you wont get any traffic if the FDB on the switch is locked down.
>
> Example:
> MAC AddressPortType
> -- --
> 00-04-75-71-AE-22 11 Dynamic
>
>
> If you lock down so that only MAC 00-04-75-71-AE-22 could be associated with
>
Andrew, good day!
> The check for ARP happens before the ipfw layer2 code so it isnt
> currently possible to filter them.
>
> switch (ether_type) {
>case ETHERTYPE_ARP:
>case ETHERTYPE_REVARP:
>return (0); /* Automatically pass */
I am a bit confu
> Come's with fbsd 5.3 drivers, but not 6.1.
> Is there an easy way out?
Use sk(4) driver. It supports DGE-530T:
-
skc0: port 0xd800-0xd8ff mem
0xdfffc000-0xdfff irq 10 at device 7.0 on pci0
skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x1)
sk0: on skc0
sk0: Ethernet address: 00:0d:88:6
Tim, good day!
> >Use sk(4) driver. It supports DGE-530T:
> >
> Is that driver not built into the kernel? If not and all I need to do is
> rebuild the kernel, ok, I can do that.
It depends on what kernel you're using. If you are at GENERIC kernel
(the default kernel at the freshly installed syst
> I'm eyeing these lines from dmesg suspiciously:
> pci0: at device 8.0 (no driver attached)
> pci0: at device 9.0 (no driver attached)
The last one is your NIC.
> I'm posting the entire results you requested below.
<...cleared all but relevant lines...>
> # uname -r
> 6.1-RELEASE
>
> # pciconf
Tim, good day!
> I'm probably better off doing the patch. Though, honestly, I've done very
> little actual 1 on 1 patching.
> If I remember right its:
> # patch src-file < patch-file
> (Maybe this'll be a good chance for me to sneak a peak at some real NIC driver
> code to get an idea how it's don
> The patch-file that will do the job is attached to this message.
Oops, forgot to attach the file.
About your previous message: lines aren't line up because you should
extract the patchfile from the 'raw' PR, see the link at the bottom
of the PR.
--
Eygene
--- skORIG/if_sk.c Sat Jul 8 13:5
Tim,
> Upon reboot, dmesg gives me this:
> skc0: port 0xdc00-0xdcff mem
> 0xdefec000-0xdefe irq 11 at device 9.0 on pci0
> skc0: unknown media type: 0x31
> device_attach: skc0 attach returned 6
Seems like the same problem as mentioned in the
http://lists.freebsd.org/pipermail/freebsd-stable/
Fabricio, good day!
> I'm developing a network application which needs *to intercept* a packet
> (not just *copy* a packet, like libpcap does), move this packet into my
> application (userland), do some checking in the packet and according
> with some heuristics, the application may change the payl
> I can create VLAN attached to this interface, and this seems to work
> but is there anyway to speed up the tagging process ? (ifconfig tells
> this interface does hardware tagging)
Search for 'vlanhwtag' in ifconfig(8).
--
Eygene
___
freebsd-net@freeb
Li, good day!
> By ping'ing 255.255.255.255 from FreeBSD (mostly RELENG_6 with some
> unrelated patches) or Mac OS X, I got response from another subnet (I
> guess that there is some configuration problem in the network, though),
> but no boxes (running various operating systems) on local network
I am CC'ing this message to Gleb Smirnov. Gleb, my apologies if you're
not interested in this stuff.
> When FBSD is pinging 0x it does not use the Ethernet broadcasts,
> when the link-level destination MAC is set to 0x, using some
> 'known MAC' instead. For the network broadcas
Bruce, good day!
> With FreeBSD's stack, sending packets to the undirected broadcast address
> INADDR_BROADCAST will result in the first ifnet with IPv4 configured and
> IFF_BROADCAST set being selected as the source ifnet. See ip_output.c for
> details.
May be I didn't understood you, but you
Tadaaki, good day!
> This seems to be the same problem as kern/99558: "FreeBSD 6.1 can't send
> packets to INADDR_BROADCAST".
>
> Maybe andre has some thoughts on how to fix this issue? (I'm CC'ing him.)
Exactly, thank you very much for the pointer!
> It seems to me from the PR above, that befo
Bruce, good day!
> >I think that this confirms my findings. Have you tried to look at your packet
> >with tcpdump? Link-level MAC should be set to your routers one, not to yhe
> >0x.
> >
> I saw this as well. The behaviour is actually as expected. FreeBSD has done
> this for years. Some
>I need some help on enabling VLAN interface on an ethernet interface.
>Please provide me the steps to configure and enable VLAN interface on
> FreeBSD 6.0 OS.
Is your Google worse than mine?
See http://people.freebsd.org/~arved/vlan/vlan_en.html, the third
link in Google on the request 'f
or ifp and in case it is not that interface to check the list.
> This will fix the problem in case of vlans and will leave the old
> behavior for the other cases.
>
> Any comments?
I've slightly elaborated his idea and commented on it:
Sun, Mar 04, 2007 at 09:22:03AM +0300, Ey
Bruce,
> >And a question: can anyone say if my patch will break some known
> >good behaviour and if the current behaviour of if_bridge is based
> >on some logic I am currently failing to understand.
> >
> I would greatly appreciate it if you could look at the combined M_PROMISC and
> 802.1p pat
Bruce,
> >In my case if_bridge drops off the packet because firewall fails to
> >recognize the packet as good: the interface that is passed to a
> >pfil_hooks is bad (I mean not the one expected).
> >
> The ifp which your patch changes is that of the mbuf chain when bridge_input
>determines it i
Roman, good day!
> Lets assume that we have two interfaces that are joined to bridge.
> I'll call them as A and B. Both has a distinct MACs.
>
> Now we have two cases for behaviour of filtering. The first case that
> we will behave like real hub between the physical interfaces and its
> virtual l
> >
> > +/* Give a chance for ifp at first priority. This will help in case
> > we
> > + * the packet comes through the interface with VLAN's and the same
> > + * MACs on several interfaces in a bridge. Also will save some
> > circles
> > + * in case dst interface
Bruce, good day!
Tue, Mar 06, 2007 at 04:00:10PM +, Bruce M. Simpson wrote:
> Eygene Ryabinkin wrote:
> >I am awfully sorry, but you're seem to be mistaken:
> Thanks for clarifying this. That'll be because I didn't read if_bridge that
> far. ;^) In my original
Yar, good day.
Mon, Mar 12, 2007 at 02:20:56PM +0300, Yar Tikhiy wrote:
> On Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
> > Eygene Ryabinkin wrote:
> > >
> > >Speaking about vlan problems: the original problem is to do something
> > >with V
Bruce,
Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
>
> >Speaking about vlan problems: the original problem is to do something
> >with VLAN interfaces only because they are sharing the MAC of their
> >physical parent. The problem itself is not VLAN-specific -- if there
> >will be
Yar,
> > 2. In the case where 802.3ad trunking is implemented, the same Ethernet
> > address may be used by multiple physical interfaces.
> >
> > 3. As Eygene explained well: there are a number of consumers of
> > Ethernet frames in the stack. As if_bridge may potentially be passed
> > mbuf c
Yar, good day.
> > >>Probably because if_bridge is written for Ethernet, 802.11 and
> > >>may be some other 802 interfaces:
> > >>-
> > >>DESCRIPTION
> > >> The if_bridge driver creates a logical link between two or more IEEE
> > >> 802
> > >> networks that use the same (or ``simi
> Here it is. I'll check it for compilation this evening and I hope Eygene will
> be able to put it in a production for testings.
The system with 6.2 and this patch is living since yesterday. No problems
were spotted. I will try to put this patch into another, busier system,
but this will not be
Good day.
We are
--
Eygene
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Good day again.
Sorry, hit the 'Send' button prematurely.
So, we are currently trying to fix kern/109815 and the advice is needed
on the current and the desired behaviour of L3 filtering on the if_bridge.
We're talking about the case when the packets coming to the if_bridge
interface are destine
Bruce,
Tue, Mar 13, 2007 at 11:36:54AM +, Bruce M. Simpson wrote:
>
> In short: M_PROMISC exists to easily identify frames which were received
> promiscuously, to prevent infinite recursion, and to simplify code which needs
> to re-enter ether_input().
>
> M_PROMISC is a flag introduced by N
Good day.
Tue, Mar 13, 2007 at 08:50:29AM +0300, Eygene Ryabinkin wrote:
> Sure. And that is why all switches that can bear the IP on their
> interfaces have distinct MACs for each interface or/and the only
> one interface can have the IP. And that is why I am going to
> add the para
Julian, good day.
> >+.Pp
> >+The packets destined to the bridging host will be seen by the filter
> >+on the interface with the MAC address equal to the packet's destination
> >+MAC. Be prepated to the situation when some of the bridge members are
> >sharing
>
> prepated to ?
> prepared for? ??
John, good day.
Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote:
> > >
> > splx() and friends have been no-ops since FreeBSD 5.x was branched.
> > Synchronization is now done using other mechanisms such as mutexes and
> > spin locks. See the new man page locking(9) in -CURRENT.
>
> It d
Good day.
Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote:
> You're right, thanks for spotting the error. The corrected patch
> is attached.
After some iterations with rik@ we came to a next version of an
if_bridge.4 patch. Comments are welcome.
--
Eygene
--- if_br
Tue, Mar 27, 2007 at 10:20:40PM +0400, Roman Kurakin wrote:
> Eygene what about the next patch for physically input filtration?
> I guess we need a separate PR and a thread here for it.
Yes, I will port it to the new if_bridge.c. The end of this week is
a good estimate for the patching and testing
Zhu, good day.
Wed, Mar 28, 2007 at 01:26:54PM +0800, Zhu Yan wrote:
> Hi, Everybody.
>
> In FreeBSD, I write a program in python(2.4.4 & 2.5), which include a
> broadcast routine.
>
> But, I send the broadcast in FreeBSD, it's different from others OS, like
> Windows, Linux...
>
> When I send
101 - 143 of 143 matches
Mail list logo
