After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653775 - [Patch] GSSDP does not work on OpenBSD
[Patch] GSSDP does not work on OpenBSD
Status: RESOLVED FIXED
Product: gssdp
Classification: Other
Component: General
unspecified
Other OpenBSD
: Normal enhancement
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-06-30 19:54 UTC by Jens Georg
Modified: 2019-02-22 09:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Fix gssdp functionality on OpenBSD (2.89 KB, patch)
2011-06-30 19:54 UTC, Jens Georg 		committed Details | Review

Description Jens Georg 2011-06-30 19:54:42 UTC 
Created attachment 191058 [details] [review]
Fix gssdp functionality on OpenBSD

GSSDP is currently broken on OpenBSD due to slightly different parameters necessary for IP_MULTICAST_TTL and IP_MULTICAST_LOOP as well as SO_REUSEPORT vs SO_REUSEADDR.
Comment 1 Jasper Lievisse Adriaanse 2011-07-04 14:03:46 UTC 
At least it gets past the previous problematic point, so ok for the diff.

Now I'm getting crashes right after the main dialog is painted:
Program received signal SIGBUS, Bus error.
[Switching to process 30259, thread 0x207751800]
0x000000020f321d3a in strlen () from /usr/lib/libc.so.58.3
(gdb) bt

+ Trace 227654

  • #0 strlen
    from /usr/lib/libc.so.58.3
  • #1 g_strdup
    from /usr/local/lib/libglib-2.0.so.2800.0
  • #2 resource_available_cb
    at gssdp-device-sniffer.c line 328
  • #3 gssdp_marshal_VOID__STRING_POINTER
    at gssdp-marshal.c line 140
  • #4 g_closure_invoke
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #5 g_signal_handlers_block_matched
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #6 g_signal_emit_valist
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #7 g_signal_emit
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #8 resource_available
    at gssdp-resource-browser.c line 755
  • #9 received_discovery_response
    at gssdp-resource-browser.c line 816
  • #10 message_received_cb
  • #11 gssdp_marshal_VOID__STRING_UINT_INT_POINTER
    at gssdp-marshal.c line 95
  • #12 g_closure_invoke
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #13 g_signal_handlers_block_matched
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #14 g_signal_emit_valist
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #15 g_signal_emit
    from /usr/local/lib/libgobject-2.0.so.2800.0
  • #16 socket_source_cb
    at gssdp-client.c line 951
  • #17 request_socket_source_cb
    at gssdp-client.c line 985
  • #18 g_main_context_dispatch
    from /usr/local/lib/libglib-2.0.so.2800.0
  • #19 g_main_context_prepare
    from /usr/local/lib/libglib-2.0.so.2800.0
  • #20 g_main_loop_run
    from /usr/local/lib/libglib-2.0.so.2800.0
  • #21 gtk_main
    from /usr/local/lib/libgtk-x11-2.0.so.2400.0
  • #22 main
    at gssdp-device-sniffer.c line 653 






Comment 2


Jens Georg





          2011-07-04 14:15:16 UTC
        



er huh? I had it successfully up and running, showing incoming packets. Will revist then.






Comment 3


Jasper Lievisse Adriaanse





          2011-07-04 14:25:07 UTC
        



This is on amd64, and you are no running with MALLOC_OPTIONS :)

Set it to 'S' with:
sudo ln -s S /etc/malloc.conf

and you'll see the crash. Something or doing bad things with memory.






Comment 4


Jens Georg





          2011-07-04 15:17:52 UTC
        



Tried with sudo ln -s S /etc/malloc.conf, still works. That's with 32bit though. 

Can you attach a wireshark/tcpdump trace (filtered for udp.port == 1900 is enough)






Comment 5


Jens Georg





          2011-07-04 15:58:55 UTC
        



Same on "OpenBSD openbsd64.lan 4.9 GENERIC#477 amd64". Just works. So I suspect you have a device on your network with a weird UUID.






Comment 6


Jasper Lievisse Adriaanse





          2011-07-04 16:41:00 UTC
        



Oh, that's odd indeed.

gurthang:jasper {1281} sudo tcpdump udp port 1900
tcpdump: listening on re0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
18:39:01.026184 192.168.178.89.ssdp > 239.255.255.250.ssdp: udp 141
18:39:01.033558 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 257
18:39:01.034233 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.062745 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.062749 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.062751 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.062753 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.062754 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.062755 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 293
18:39:01.062757 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 337
18:39:01.062758 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 321
18:39:01.062909 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 319
18:39:01.533231 192.168.178.89.ssdp > 239.255.255.250.ssdp: udp 141
18:39:01.538599 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 257
18:39:01.540528 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.541158 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.543070 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.543721 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.545690 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:01.546252 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:01.548308 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 293
18:39:01.552257 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 337
18:39:01.553729 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 321
18:39:01.556000 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 319
18:39:02.043208 192.168.178.89.ssdp > 239.255.255.250.ssdp: udp 141
18:39:02.048739 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 257
18:39:02.049408 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:02.050694 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:02.059160 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:02.059164 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:02.059165 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 266
18:39:02.059167 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 227
18:39:02.059168 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 293
18:39:02.061284 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 337
18:39:02.062757 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 321
18:39:02.064203 192.168.178.1.ssdp > 192.168.178.89.ssdp: udp 319
^C
91 packets received by filter
0 packets dropped by kernel

The UUID of my router (which would be the only device to cause the crash here):
uuid:75802409-bccb-40e7-8e6c-001F3FBE116A






Comment 7


Jens Georg





          2011-07-06 16:54:33 UTC
        



yes, but there are more uuids than just that. Can you attach a pcap dump file?






Comment 8


Jasper Lievisse Adriaanse





          2011-09-05 17:40:39 UTC
        



I've since been unable to reproduce the crash at multiple occasions. Ill close this ticket now as the initial issue has been resolved.