Newest design digital signage

[Reed]

Dear ,
We are so glad to hear that you are also in the field of presentation equipment.
This is Redins from Hongbao which is focused on Interactive Displaying 
Equipment. We have different Interactive Touch Screen, Digital Signage, etc.
If you have more question, we would like to give you more information about our 
products.
Thank you for your time.Best regards, Mr. ReedSales 
Manager Chongqing Hongbao Technology Co., Ltd.Address: Building 9, Area C, 
Jinglong Industrial Park, Jiulongpo District, Chongqing, China
SKYPE: iec05_1Office: 0086 23 8867 0519Whatsapp: +86 17784283905
Contact of General Manager,Mr.Alan TanSKYPE: sendaindustryWhatsapp/Cellphone: 
+86 1800837

91Q6zf9ZNgNixxFRU0uLkcWYyWQs4cr11ytFqAGyffqxjFCbOiyBW0xW5RxDoGUAOLhY4ZqjkVw5MoETkFEMEQ501xAz23aykPJxoD7PSfh0tsaGcEjJ28WYGgXxoQggLXKXF6uHxPTpy5xzmTmoKqwcSKR8FAq1Y0fvHd16aBcdexpBIoavuSwlry4Vem1XoSqyP1R9Sge8djXlkgphpVx6uU4886ROAfOm6RLHw1CdEn78BJAYWKxtkk4VXJ0MpqyYuBetvHKoijs6NWxpvTRPHl1MNQKN1QOeP8D0u7se09a0SX80bAgvyIh9zsFEXWmsvegFjxVoqCPya0UPIJCqziF7Qtq1rNh3MHvDHsHEES5VTIYyyQWdkWScy9OP6UWClLMtug8f2XMHcJe8vRsBR3IPPj5xESxKVtz7Wv3iHHbm9aZOVGkfrlLi3WDbbAAaq1MJa6bZNaT9RlGEjgCYxijzIh4ZRR7771W8ogEOukrgsBqHgYSUXCC8Hd1S2c7V3L2Qpxg2BOudQ276QmJSZc9uoNqbfMLhcvdGzzhIIPj98phF5U1FteWQBxrC65NP3c0lPqxh50a9S0mZvL5kK5OXym417ECC1u5VoWPFnKAt4NYAas7l0t4Xn2Mslv9roy7oUqAzVqXZvlTLotRFxgCyp8yl9njSB94vFzFJRypAw5r1913REtT7WyYMSfpy64nmgn5OO7OZQ12jGwc8jre8fXz6ATRC8RtrI5KLVe3wFTgUwE5l2heFQf6jOYdUgbQZyBBBMrc4nHslGEAWOvARCNAsYrWW08ft2gmV3tzA4ai9MLC9oh6LBZnK09Dkvg3esYiqiFSkWZMsvrFdONyI2uS3TBUUQe5O63GOscQIpMPBcUeztqvIHkcX6fwHLYuHUYmsKRLCWPjgFgQZmkqpIm6LQJHcF9Xqh7GeyMPBFTLS1WhPpxkrx4YxRBB09yWMRTYxABrzvPKPBdKUrSN8OwSd88mWbO
 
r6WZ17YJfN6KWIk9WDRGzhKNXl1KprfuoGnDSBcCWHD023A9TZcI5ufam91F6dkNxCmfkGgkreKREKKUKRRpfwoUrdhJAwwJmPsqHkPcIRhRKnvBo7VelVy1drO7pxKUI1vOhkcp2FGoexa3HFltBhnrhqcfwINb6n8ISGk3VvcGeaNGhKpJchiqD3xQ7WTkSvhQorb0lhy55Hc7DwYMi3YP4I4O9tWYCSOISWiQzonVIdlWQqdBY61OxsMGmmRSlztdTueGe7cUF36Rm8YIfl0vQZbq9BtdwvA9J83mbwmQU68tlVjeo8CZzXmTiOwCEZoatX7e5BxIYaBKRH4eifOnTAAML94n0KbUIX0oO49MBT1pmC1AKijpa0hTnlsVx9IdYG1THGqd51LZyap97tCHqMJIG71sCdfraOqFA8T4R5j9ehkcViN3x1McXjcAFXBRLkOKKKzZAyQlsAuoMOxjqcU91eHhVipTurnUtAsaJOtYbrJnOOOQqirzpFIv2i4i9WQ0cAVcmnACJWYAvks7uytc0NuORX7qJbOeAJaeSCt3HOQtG80IPWNAsEZp57kpf9Sy7JZLadeS4qubX17JWpANneMWJL9Lh4NyWimW9eyCIVv1aOs4ZBsQy5aSX32o4tA0CWfEFbzIRY4rIKLVj5MFCXZR7tZ5c9xekvpdzNoO1KYA0Jach65ZHUnEXnwcbuwHqP6clymvGXESYoQoiMO53yxp8KgbgcCxeg9aCXRJKzjJgvFyx7ToGqERiH4Ahbetl7EHfGMkV4kufO9C4ID9idQNCiSUTgszkPo9QXjQkytB69Ctxrwyx5a7gR5WNRrECK9qq0L6pMOJJfHsFonsKT2fEgSZSm2t7PYl0c3xFq9Khqn19ChpuZUJITL97Md3JlCUglstlPMkKiXdTRPg4DY8VfD6qUqTc50WOtKO9N3FcAYqWxffWWY6mtY0Il2rpS7Eh1pq717gzjVlgcaTEaXg6Uzku
 
J5OLCfjsk8V8P8UPHw3xDKva9MeVRxnr4WnVivX3CSW3fKP23qpowNQZzDCP1oBMLt4SKYwcyZVKNsVoXbSq8ZVh5omET72dhaiMGWi4UdPwR5b7IdRPvbDMyNNlCRiqXItC99I1TNwVaop0ceWFfcH6wwdS9Ws2Uoy9CyXzuQWIEIC9nN9nVDbK0n6DVPSWlu0LQgnDgmapgZrOT4vmN46hdN8esjEFY0maIQj6pw7ysLu0VhJQkw9hnJy289aWIvqfCg63LpWgXxPrj7iazNksQ5NYhhXflaQWkeoFbG5VzSkPU6J0QZnVbYpxt7LurHVMHS64JDZTIpTYLX4axXplNVLlPQb4UAtRXx81ZEhd0tcL5rMv2BWuizZM7LeSrUZ7V10dP3aTFbljIZgo4G1jEZznylTeqoL5u5P4qyGZq3O6eF48uPNLTFsWrDFu9VshqfPD9bYwZ2TBbt9ShLKABZcOCTDMScPuAwFYQrYiRgLRMRKXtNcobRGq300gybENco0ENa2QMrJkek2K9Fj5ZqiJQfUPqIJFCXEnR59iKmBK7mcJYf6TSyOM5gOygdp4H3HgGES3w0kDOyBu2bQaBQN49ShAhA2xWx24EW2km3nSdaXxFjv4mftQgC6NmiMVXNHhwxP68vNytVQZVKVX4YaG3bN1PfY4grUqtF08tpVQrVnlM7SBmOQZC0dkJOgTxIh10qwfJNtF2ke8OrfImmIsBVNssGoF82jJDllmBDRzkaXiL4whyywb0Pq5C3M3pOxZ1vut6T7Ju97qYvGn966zv8IOUgKxQO9wDXhgA2bFrMGQH076npTiHXuTMFyQ9zSGZAN0eqN7Vr8IrS6U8D9rURPFsntUukwRTZR7c6RXBMnfPLrUzEHvprL8K7xQXTCAUgOs0ZH2LcP8tzQHWylPD1rsdIm5y1ZI9NkyWZUzWEJdBDFbgQTpyNXTPmeiCBuKd7YFehLXELTYheQA3bOI7A9mQrJzK
 
BXkaZZtFZWY4WLMUYCAvEerNMDCXCPNybc2OyOienV4fPDaPmsRO846nwxolnv298qTJIYmajl8JabX8sMBaXZp76Ei0pWRRSU7pKr6o6HuNVndkAfTAUSb90LD4GlKmuhQf4xo1Gc4guCbIrXpa3gW0JYoYN2HKW8iEwYf3RRUHOVEozUCJWAjekQw69pdDvjkmkxbtHmjblebNj0pSqYNmO3jGs9TrEhcuBi32J91Ag7S6EIN80kdxwXxgev0ysRx42Gc0Wm9gXd5Hbc1JmLrj3EYDLNOd8s7pAN4YvMcDaWAiSQ41thbHpd1nIze8yW7u5G7o83ezyO864GLVIMJRhqZmMHfWx34eP6ccIGTq3C8B4Ui2OjqLcgcEGKBqNh1vKUhYtyc1TjOEiohRpd7eCi2yTyvY4sCLACRaCjzf7oSTsxlitK1AaNSrSI5U3eXrG34Gw7e5ES6eq96lccukq2BMKpiUeEbTrrcotFLmvWWhGE1JCKIRJC0EsiW7PkRZGdNYWHRwq8Pu6j55nzhuVk9OryWbJEwa5WAtQ2MUSbqAMvx8cQKg3m4m3YxoKGNMBFp9ICfkMnBJUz1V0OZTTg7ISepSvo9boDY75npzBptFLkruWBnWHTTlyHhucmPndplgAUQCppiuNrWyMVWT1duvKDzo6UneA5slZaT2LKxiBoy6KJIhqWm0VPwXkswu13THZBzB1U7gGcTl5sDmc5OEIrq9EWHje2gxuQ79a6gwO6kJWbRRO9hVffYxapX4cN2DVlQeluc6PiPC7Hct5Pu4LkieSAYK9bj13GNAkDwkXb6XqlptdtZniXSA3BmKvrWEYOyrTC9sia6zekOwauxFcVI5OcwIgLPwesYCMYzAkx48RimINPA0Uhr35sCH5qbwlAlMmbJcVWkFQzevPOUrbOBW0VwjlSvUlyNgXAmC5n5XXMcwd7RhwJkxZoLqFpQ2rqjiMYxfsimOIEZdJ06d0eoCdghzO
 
VXFw2wwtTJfzCOdnwOloyHEjC2c2G5wHYrxlGhF7sKPgQEopafGrWagdilT0juMOdxBahSGf8dWNSotYDNRrp4LOaj2lnFNXX13i3d7hyqj
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to 

[Bug 171744] [PATCH] Fix wake(8) command not sending proper WOL packet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171744

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2185
   ||79

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218579] Wake on Lan doesn't work for bge NIC driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=1717
   ||44

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: WiGig feature / support?

[Chris H]

On Mon, 19 Mar 2018 16:30:00 -0700 "Adrian Chadd"  said


hi!

Hi! Thanks for the quick reply, Adrian!


There's a lot of work to do for this card. The challenge is it's a
completely different thing that our stack needs to understand /and/ it
also kinda pretends to be a PCIe end point too.

Ah, OK. I was afraid I might find it wasn't supported.


I'd start by looking at what the linux stack/driver does for 11ad.
We'd at least have to add 60GHz channel support. I don't know what
else is required for 11ad as I haven't really looked in a few years.

OK. I'll have a look and see what I can come up with. I'll poke you
when I can come up with anything worth while. BTW I meant what I said
about sending you one of these cards. Lemme know if you're interested.

Thanks again!

--Chris




-adrian



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218579] Wake on Lan doesn't work for bge NIC driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

Cy Schubert  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #7 from Cy Schubert  ---
The patch attached to this PR also works with stable/11 and releng/11.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multicast/SSDP not working (on VLAN interface)

[Rozhuk Ivan]

On Mon, 19 Mar 2018 16:11:05 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> Are you running with "firewall_type="simple""?
> If so it is set to block all 224/4 packets, see this part
> of /etc/rc.firewall:
> # And stop draft-manning-dsua-03.txt (1 May 2000) nets
> (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST
> (class D), and class E) # on the outside interface
> ${fwcmd} table ${BAD_ADDR_TBL} add 0.0.0.0/8
> ${fwcmd} table ${BAD_ADDR_TBL} add 169.254.0.0/16
> ${fwcmd} table ${BAD_ADDR_TBL} add 192.0.2.0/24
> ${fwcmd} table ${BAD_ADDR_TBL} add 224.0.0.0/4
> ${fwcmd} table ${BAD_ADDR_TBL} add 240.0.0.0/4
> 
>   ${fwcmd} add deny all from any to "table($BAD_ADDR_TBL)" via
> ${oif}
> 
> Your route effected this as your packets are no longer trying to
> use an all interfaces path, but a specific interface, and that is
> probably not ${oif} of your firewall.
> 

One more fw tip: pf by default drops all IP packets with options, so IGMP does 
not work.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: WiGig feature / support?

[Adrian Chadd]

hi!

There's a lot of work to do for this card. The challenge is it's a
completely different thing that our stack needs to understand /and/ it
also kinda pretends to be a PCIe end point too.

I'd start by looking at what the linux stack/driver does for 11ad.
We'd at least have to add 60GHz channel support. I don't know what
else is required for 11ad as I haven't really looked in a few years.



-adrian
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

WiGig feature / support?

[Chris H]

Apologies in advance, should this have gone to @wireless, or ...
That said; I'm performing some R on an efficient alternative to gigabit
networking w/o cables. To that end; my Atheros (QCA9005) WiGig (7Gbps tri-band) 
half mini-pcie card just arrived, and my target test rig (laptop) will arrive

next week. So I suppose I've sort of put the cart before the horse here. But,
any chance I can pull up this card on FreeBSD? If work still needs to be done,
anything you'd like to point me at? In fact, if need be, I'd be willing to send
one of these cards to someone working on this (@adrian ?). :-)

Anyway, if anyone can further enlighten me on WiGig on FreeBSD. I'd *greatly*
appreciate it. :-)

Thanks!

--Chris


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multicast/SSDP not working (on VLAN interface)

[Rodney W. Grimes]

> Dear List
> 
> I was unfortunately unable to find a way to search this mailing list's 
> archive; so please bear with me if the question was answered before.

google:  site:freebsd.org Then what you are searching for

is one way to search all of freebsd.org for what you are seeking.
> 
> My goal is to have DLNA clients (VLC, Heos music system, ...) in 
> multiple networks discover a MiniDLNA server.
> 
> The server shows up in VLC when it starts (or is restarted) after VLC is 
> running. If the server is already running when VLC is started, VLC does 
> not detect/find the server.
> 
> Very much like this source states:
> https://sourceforge.net/p/minidlna/bugs/94/#8c8f
> I suspect a problem with the M-SEARCH messages the client is sending.
> 
> Using tcpdump on the interface where M-SEARCH from VLC are coming in, I 
> can indeed see the packets/messages arrive (they are sent from the 
> client to 239.255.255.250). So it is is not a router or switch or 
> whatever blocking the packets.
> 
> Now, if I (manually) add a static route for 224.0.0.0/4 via the 
> interface the M-SEARCH messages are coming in, everything starts to work!
> 
> route add -net 224.0.0.0/4 -iface re1.32
> 
> The (main) problem here is that I have multiple networks with clients in 
> them. So a static route does not REALLY solve my problem.
> 
> Also I do not (yet?) understand why the route should be required.
> 
> What I see is that ifmcstat -f inet -i re1.32 does not list a membership 
> for 239.255.255.250 when it is not working, but does list the membership 
> when it is working...
> 
> So I suspect that "something" is dropping the M-SEARCH packets for some 
> reason after they are received. And I cannot get rid of the feeling that 
> it has something to do with the fact that the incoming interface is a 
> VLAN interface...
> My first guess, anti spoofing, seems not to be the problem (I am using 
> ipfw and "not antispoof in" but that does not seem to drop any traffic).

Are you running with "firewall_type="simple""?
If so it is set to block all 224/4 packets, see this part
of /etc/rc.firewall:
# And stop draft-manning-dsua-03.txt (1 May 2000) nets (includes 
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E)
# on the outside interface
${fwcmd} table ${BAD_ADDR_TBL} add 0.0.0.0/8
${fwcmd} table ${BAD_ADDR_TBL} add 169.254.0.0/16
${fwcmd} table ${BAD_ADDR_TBL} add 192.0.2.0/24
${fwcmd} table ${BAD_ADDR_TBL} add 224.0.0.0/4
${fwcmd} table ${BAD_ADDR_TBL} add 240.0.0.0/4

${fwcmd} add deny all from any to "table($BAD_ADDR_TBL)" via ${oif}

Your route effected this as your packets are no longer trying to
use an all interfaces path, but a specific interface, and that is
probably not ${oif} of your firewall.

> 
> Do I miss something obvious or can someone point me in the right direction?

Probably just remove the 224.0.0.0/4 from the above table and
things may start to work.

> 
> VLC v2.2.8 is running on Mac OSX 10.12. MiniDLNA v1.2.1,1 is running on 
> FreeBSD RELEASE-11.1.
> 
> More information can be found in the FreeBSD forum [1].
> 
> 
> Thanks heaps
> andreas
> 
> [1] 
> https://forums.freebsd.org/threads/minidlna-not-discovered-multicast-issue.64947/
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multicast/SSDP not working (on VLAN interface)

[Rozhuk Ivan]

On Mon, 19 Mar 2018 22:29:12 +0100
Andreas Scherrer  wrote:

> Now, if I (manually) add a static route for 224.0.0.0/4 via the 
> interface the M-SEARCH messages are coming in, everything starts to
> work!
> 
> route add -net 224.0.0.0/4 -iface re1.32
> 
> The (main) problem here is that I have multiple networks with clients
> in them. So a static route does not REALLY solve my problem.
> 
> Also I do not (yet?) understand why the route should be required.
> 
> What I see is that ifmcstat -f inet -i re1.32 does not list a
> membership for 239.255.255.250 when it is not working, but does list
> the membership when it is working...

That is because many software use old dumb multicast socket api.
It requres that use add route to mc net via one net iface.
If no mc route present then OS will send all mc packets to default gw, using 
unicast gw mac addr instead of specific mc mac addr.
On linux all same.

Mine https://github.com/rozhuk-im/ssdpd can send and receive mc packet via many 
net ifaces.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Multicast/SSDP not working (on VLAN interface)

[Andreas Scherrer]

Dear List

I was unfortunately unable to find a way to search this mailing list's 
archive; so please bear with me if the question was answered before.


My goal is to have DLNA clients (VLC, Heos music system, ...) in 
multiple networks discover a MiniDLNA server.


The server shows up in VLC when it starts (or is restarted) after VLC is 
running. If the server is already running when VLC is started, VLC does 
not detect/find the server.


Very much like this source states:
https://sourceforge.net/p/minidlna/bugs/94/#8c8f
I suspect a problem with the M-SEARCH messages the client is sending.

Using tcpdump on the interface where M-SEARCH from VLC are coming in, I 
can indeed see the packets/messages arrive (they are sent from the 
client to 239.255.255.250). So it is is not a router or switch or 
whatever blocking the packets.


Now, if I (manually) add a static route for 224.0.0.0/4 via the 
interface the M-SEARCH messages are coming in, everything starts to work!


route add -net 224.0.0.0/4 -iface re1.32

The (main) problem here is that I have multiple networks with clients in 
them. So a static route does not REALLY solve my problem.


Also I do not (yet?) understand why the route should be required.

What I see is that ifmcstat -f inet -i re1.32 does not list a membership 
for 239.255.255.250 when it is not working, but does list the membership 
when it is working...


So I suspect that "something" is dropping the M-SEARCH packets for some 
reason after they are received. And I cannot get rid of the feeling that 
it has something to do with the fact that the incoming interface is a 
VLAN interface...
My first guess, anti spoofing, seems not to be the problem (I am using 
ipfw and "not antispoof in" but that does not seem to drop any traffic).


Do I miss something obvious or can someone point me in the right direction?

VLC v2.2.8 is running on Mac OSX 10.12. MiniDLNA v1.2.1,1 is running on 
FreeBSD RELEASE-11.1.


More information can be found in the FreeBSD forum [1].


Thanks heaps
andreas

[1] 
https://forums.freebsd.org/threads/minidlna-not-discovered-multicast-issue.64947/

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: netmap ixgbevf mtu

[Joe Buehler]

Vincenzo Maffione wrote:

> To receive a frame larger than the RX buffer size you need multiple
> netmap slots (as multiple descriptors are
> used by the hardware), looking at the NS_MOREFRAG flag.
> See the example code in utils/functional.c::rx_one().

This works fine -- thanks.

> Also TX may have per-slot limitations (e.g. due to the size of the NIC
> TX fifo), but this is usually > 9K, so using a single descriptor per
> packet should always
> be ok. However, you can also use multiple slots on the TX side (see
> utils/functional.c::tx_one()).

Trying to split TX frames into multiple buffers does not work, the NIC is 
sending 2048 byte frames (the buf_size I am using).

I will re-check my code.  Do I need a particular version of ixgbevf perhaps?

Joe Buehler
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218579] Wake on Lan doesn't work for bge NIC driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

--- Comment #6 from Cy Schubert  ---
I don't understand why it worked on 10.3. The WOL code was not in bge at the
time. The patch is for 12-CURRENT. I'll rework it for 11-STABLE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218579] Wake on Lan doesn't work for bge NIC driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

Koen Martens  changed:

   What|Removed |Added

 CC||g...@metro.cx

--- Comment #5 from Koen Martens  ---
Not sure what the fix is, and how 171744 is relevant (it's about the wake
command, if I understand correctly).

Just wanted to chime in. I have a machine with a bge-driven card for which WOL
worked perfectly with 10.3-RELEASE. I activated it with 'ifconfig bge0
wol_magic' and then used the wakeonlan utility on a linux (ubuntu 16.04)
machine to wake up the freebsd machine.

Yesterday I upgraded to 11.1-RELEASE (something I have put off for ages because
I was afraid something would break, but with the EOL coming up I decided to
take the risk), and WOL just stopped working.

It isn't even advertised anymore as a capability in ifconfig:

# ifconfig -m bge0
bge0: flags=8843 metric 0 mtu 1500
   
options=8009b
   
capabilities=8009b
ether 00:1e:c9:5b:75:11
hwaddr 00:1e:c9:5b:75:11
inet 10.1.3.8 netmask 0xff00 broadcast 10.1.3.255 
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
supported media:
media autoselect mediaopt flowcontrol
media autoselect
media 1000baseT mediaopt full-duplex,master
media 1000baseT mediaopt full-duplex
media 1000baseT mediaopt master
media 1000baseT
media 100baseTX mediaopt full-duplex
media 100baseTX
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP

Needless to say, 'ifconfig bge0 wol_magic' doesn't enable it anymore either.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 206721] FreeBSDs DHCP client(dhclient) does not support the interface-mtu option(option 26).

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||freebsd-net@FreeBSD.org

--- Comment #9 from Rodney W. Grimes  ---
Put back on freebsd-net@ notification list

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 206721] FreeBSDs DHCP client(dhclient) does not support the interface-mtu option(option 26).

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||feature
   Assignee|freebsd-net@FreeBSD.org |c...@freebsd.org
  Flags||mfc-stable10?,
   ||mfc-stable11+
   See Also||https://reviews.freebsd.org
   ||/D4788

--- Comment #8 from Kubilay Kocak  ---
Assign to committer that resolved. Thanks Conrad!

Also track MFC's correctly, currently only to stable/11

Can stable/10 not receive it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Does FreeBSD do proactive ARP refresh?

[sthaug]

> >>  And thank you for that suggestion! The packet loss during ARP refresh
> >>  (of the destination address connected to the output interface) does
> >>  *not* happen when the box is forwarding! It only happens with locally
> >>  generated traffic.
> Should be fixed by r331098.

I can confirm that 12.0-CURRENT with the r331098 updates fixes this
problem for me for locally generated traffic. The ARP entry seems to
be refreshed around 4 seconds before expiry, and there is no packet
loss.

Transit traffic (non locally generated) also works as before, the ARP
entry is refreshed before expiry and there is no packet loss.

Thanks for the quick fix! Now waiting for the MFC :-)

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"